# Gentoo Raspberry ... warum Rust?

## alexander_ro

Hallo,

seit heute versucht emerge rust auf einem Raspberry und anderem zu installieren vermutlich weil ich da den certbot wegen SSL-Zertifikaten brauche. Rust konnte man schon auf meinem Alien mit 16 GB nicht übersetzen das wird dann wohl auf einem ARM mit einem GB auch nicht besser gehen.

Gibt es da eine Möglichkeit wie man das verhindern kann?

Viele Grüße

Alexander

----------

## Christian99

hm, zunächst spricht erstmal nix dagegen, rust auch auf einen raspberry zu bauen. wenn der speicher nicht reicht, einfach MAKEOPTS="-j1" setzen.

Desweiteren gibt es rust-bin, da ist der rust compiler dann fertig gebaut drin, und er wird nicht bei dir selbst gebaut.

Wenn du es aber nicht haben willst, musst du rauskriegen, welches andere Paket rust als Abhängigkeit hat. Wenn du -t (--tree) an den emerge befehl anhängst, sollte das zu sehen sein.

Dann darfst du dieses paket halt nicht installieren.

----------

## alexander_ro

Der lies sich mit 16GB auch nicht mit -j1 bauen. Rust glänzte nicht gerade mit Ressourcenschonender Arbeit deshalb will ich das nicht auf kleinen ARM Rechnern haben. Möglich das man rust-bin installieren könnte ob es dann läuft ist eine andere Frage.

Um in der Zwischenzeit die anderen Updates machen zu können habe ich rust Maskiert das förderte auch gleich die Problem Pakete zu tage.

```

dev-python/cryptography:0

dev-python/pyopenssl:0

```

Liegt schon an dem certbot den kann ich nur nicht so einfach weglassen:

```

equery depends cryptography

 * These packages depend on cryptography:

app-crypt/acme-1.27.0 (>=dev-python/cryptography-2.5.0[python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?])

                      (test ? >=dev-python/cryptography-2.5.0[python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?])

app-crypt/certbot-1.27.0 (>=dev-python/cryptography-2.5.0[python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?])

                         (test ? >=dev-python/cryptography-2.5.0[python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?])

dev-python/josepy-1.13.0 (>=dev-python/cryptography-0.8[python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?])

                         (test ? >=dev-python/cryptography-0.8[python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?])

dev-python/pyopenssl-20.0.1-r1 (>=dev-python/cryptography-3.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?])

                               (test ? >=dev-python/cryptography-3.2[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?,python_targets_python3_11(-)?])

dev-python/requests-toolbelt-0.9.1 (!ia64 ? dev-python/cryptography[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,python_targets_python3_10(-)?])

```

----------

## schmidicom

Wenn dir die Abhängigkeiten von certbot nicht gefallen wäre das Apache-Modul MD vielleicht eine alternative:

https://httpd.apache.org/docs/current/mod/mod_md.html

----------

## alexander_ro

Bisher waren die Abhängigkeiten ja Ok nur jetzt mag es nicht mehr ...  :Sad: 

Die Idee von Dir ist nicht schlecht sieht aber ein bisschen Kompliziert aus. Das mit der DNS-Challange ist auch nicht so einfach. Das geht dann nur noch mit dem apache.

Ich hoffe nur die bauen nicht irgendwas um das portage braucht weil das wird dann schwer eine alternative zu finden.

----------

## firefly

Es gibt auch eine reine shell script basierte Implementierung des ACME Protokolls (welches LE nutzt)

https://github.com/acmesh-official/acme.sh

----------

## schmidicom

 *alexander_ro wrote:*   

> Die Idee von Dir ist nicht schlecht sieht aber ein bisschen Kompliziert aus. Das mit der DNS-Challange ist auch nicht so einfach. Das geht dann nur noch mit dem apache.

 

Die Ersteinrichtung ist tatsächlich mit etwas Aufwand verbunden, aber wer vorher die Doku gründlich liest und beim einrichten auch die Apache-Logs im blick behält sollte das problemlos zum laufen bekommen.

Und wer das hinter sich hat fragt sich nachher nur noch: "Warum habe ich das nicht schon früher so gemacht?".  :Wink: 

Ich administriere bei meinem Arbeitgeber einen Apache-Webserver mit mehreren VirtualHosts von denen die meisten ihr Zertifikat genau so bekommen und seit es eingerichtet ist läuft die Sache wirklich sehr stabil auch über Software-Updates hinweg.Last edited by schmidicom on Thu Jun 02, 2022 11:51 am; edited 1 time in total

----------

## Christian99

 *alexander_ro wrote:*   

> Der lies sich mit 16GB auch nicht mit -j1 bauen. Rust glänzte nicht gerade mit Ressourcenschonender Arbeit deshalb will ich das nicht auf kleinen ARM Rechnern haben. Möglich das man rust-bin installieren könnte ob es dann läuft ist eine andere Frage.
> 
> 

 

hm, so viele ressourcen braucht das bauen von rust aber nicht. Ich bau das schon länger mit -j8 auf einem System mit 16GB Ram ohne Probleme. Wenn es sich auf einem 16GB System mit -j1 nicht bauen lässt, liegt es an was anderen. auf einen 1GB System könnte es mit -j1 bauen. einfach mal probieren.

Hm, keine Ahnung, wieso das mit rust-bin nicht funktionieren soll. auch hier gilt: wieso probierst dus nicht mal?

----------

## firefly

 *alexander_ro wrote:*   

> Rust konnte man schon auf meinem Alien mit 16 GB nicht übersetzen das wird dann wohl auf einem ARM mit einem GB auch nicht besser gehen.

 

Was hast du da für eine portage konfiguration gefahren (z.b MAKEOPTS, oder lag /var/tmp/portage auf einer RAMDISK?), dass dev-lang/rust nicht mal mit 16GB Ram sich bauen lies?

Ich hab mal folgenden testlauf auf meinem PC gemacht:

```
$ MAKEOPTS="-j1" ebuild dev-lang/rust/rust-1.59.0.ebuild compile
```

Aktive USE-Flags: system-bootstrap system-llvm

Beim Start war der RAM verbrauch bei ca. 9.5Gi (laut free -h, die used spalte)

Im peek war der RAM verbrauch bei ca. 13Gi

Das machte dann ca. 3.5Gi usage im peak für das Übersetzen.

Wobei man hier was abziehen muss, da ich /var/tmp/portage in einem zram (mit zstd) liegen habe.

Im peak hat die ZRAM disk (laut zramctl) ca. 1.6Gi benötigt ( Die unkomprimierten Daten lagen bei ca. 5.3Gi)

Die USE-Flags system-bootstrap system-llvm sind nicht default aktiv daher habe ich den gleichen testlauf dann nochmal ohne diese beiden USE-Flags gemacht:

```
$ MAKEOPTS="-j1" USE="-system-bootstrap -system-llvm"  ebuild dev-lang/rust/rust-1.59.0.ebuild compile
```

Beim Start war der RAM verbrauch bei ca. 9.5Gi (laut free -h, die used spalte)

Im peek war der RAM verbrauch bei ca. 15Gi

Wärend LLVM übersetzt wurde war der peak RAM bei ca 13Gi wobei ZRAM davon ca. 2.2Gi (ca. 6.7Gi unkomprimiert) im peak benötigte

Das machte dann ca. 5.5Gi usage im peak für das Übersetzen.

Wobei man hier was abziehen muss, da ich /var/tmp/portage in einem zram (mit zstd) liegen habe.

Im peak hat die ZRAM disk (laut zramctl) ca. 3.8Gi benötigt ( Die unkomprimierten Daten lagen bei ca. 11Gi)

Zusammengefasst für dev-lang/rust-1.59.0 war der peak RAM Usage wie folgt (Beide mit MAKEOPTS="-j1":

USE-Flags system-bootstrap system-llvm aktiv: ca. 3.5Gi

USE-Flags system-bootstrap system-llvm inaktiv: ca. 5.5Gi

In beiden fällen war der RAM verbrauch weit entfernt von den 16Gi.

Wenn rust bei dir mehr als 16Gi benötigt hat, hattest du wohl sehr viele parallele make jobs konfiguriert. Oder du hattest gleichzeitig irgendetwas anderes am laufen gehabt was relativ viel RAM benötigt hat.

----------

## firefly

Um zu sehen wieviel mehr RAM benötigt wird habe ich einen test mit MAKEOPTS="-j18" gemacht:

```
$ MAKEOPTS="-j18" USE="-system-bootstrap -system-llvm"  ebuild dev-lang/rust/rust-1.59.0.ebuild compile
```

Beim Start war der RAM verbrauch bei ca. 9.5Gi (laut free -h, die used spalte)

In diesem Falle war der peak RAM usage bei 20Gi

Das machte dann ca. 10.5Gi usage im peak für das Übersetzen.

Wobei man hier was abziehen muss, da ich /var/tmp/portage in einem zram (mit zstd) liegen habe.

Im peak hat die ZRAM disk (laut zramctl) ca. 3.8Gi benötigt ( Die unkomprimierten Daten lagen bei ca. 11Gi) 

Auch hier werden die 16Gi RAM von rust selbst nicht erreicht.

----------

## alexander_ro

Ist schon eine weile her damals ging das nicht mit den 16GB die das gesamte System zur Verfügung hat. Es lief nichts besonderes sonst. Vielleicht haben die ja ein paar Kinderkrankheiten ausgebaut und kommen nun mit weniger Speicher aus. Solche Test brauchen immer viel Zeit die muss man übrig haben und auf jeder Plattform machen. Fressen tut der auch so im Betrieb viel Speicher und 5G sind immer noch viel mehr als ein kleiner ARM hat. Wenn die Projekte rund um Linux so weiter machen muss man für ältere System zu Windows wechseln ...  :Sad: 

Ich werd mal schauen was sich besser eignet die Script oder die apache Version oder eine Mischung aus beidem. Muss ich erst Testen das dauert immer ein wenig.

----------

## firefly

Die 5.5G sind peak und man muss da mindestens 2.2G abziehen (da ich alles in einer RAM Disk laufen lasse) dann sind wir nur noch bei 3.2G im peak

Wobei der 15G peak später war, wo die RAMdisk mindestens 3G brauchte und dann sind wir bei nur noch 2.5G!

Scheinbar wird hier wieder nur die hälfte gelesen um dann argumentieren zu können das alles scheiße sei...

Und wenn man einen kleinen ARM hat dann sollte man eh die Pakete nicht auf diesem Gerät selbst übersetzen sondern auf einem Gerät das potenter ist...

Besonders bezogen auf die benötigte Zeit die das bauen aller pakte benötigt.

Wobei das Ergebnis des Tests nicht direkt auf einen ARM übertragbar ist. Denn der Test wurde auf einen x86 PC gemacht. Gut möglich das auf einem ARM das ganze anders aussieht.

 *Quote:*   

> 
> 
> Rust konnte man schon auf meinem Alien mit 16 GB nicht übersetzen

 

Dein Argument da es mehr als 16G braucht  bezog sich auf einem "Alien". Und dann passt dein Argument bezüglich kleinen ARM überhaupt nicht...

----------

## firefly

 *alexander_ro wrote:*   

> Ist schon eine weile her damals ging das nicht mit den 16GB die das gesamte System zur Verfügung hat. Es lief nichts besonderes sonst. 

 

Ohne zu wissen wie die Konfiguration von portage war und ob eine RAM disk genutzt wurde oder nicht lässt sich das ganze nicht beurteilen

----------

## mike155

 *alexander_ro wrote:*   

> seit heute versucht emerge rust auf einem Raspberry und anderem zu installieren vermutlich weil ich da den certbot wegen SSL-Zertifikaten brauche. 

 

Ja, seit heute ist dev-python/cryptography-37.0.2 stable. Die neue Version benötigt Rust - im Gegensatz zur alten Version 3.4.7-r3. 

Es gibt auch einen weiteren Thread dazu: system update requires rust - why?

----------

## alexander_ro

Doch doch das passt ... siehe oben da steht das es meine ARM Platinchen nicht können werden.

Warum sollte der Compiler auf dem ARM das plötzlich in 300MB können der muss auf beiden die selbe Arbeit machen?

Das ist der freie Speicher wenn ein System ohne Desktop läuft.

Der Alien Test ist älter daher kann es sein das es nun mit unter 16GB auch geht und ich kann durchaus beurteilen ob das System an anderer Stelle viel Speicher verbraucht. Deshalb bin ich darauf nicht eingegangen. Nein es gab keine RAM Disk. Ich habe das mit verschiedenen unter anderem im Forum hier vorgeschlagenen Konfigurationen getestet. Es hat nie funktioniert und da habe ich es aufgegeben. Wenn ich erst mal was aufgegeben habe fange ich es nicht wieder an wenn es nicht einen wichtigen Grund dafür gibt. Für rust gibt es aktuell keinen wichtigen Grund.

... und ja es ist alles Scheiße woher weißt Du das?

Nicht ärgern das sollte ein Witz sein.

Das ist mal Englisch das sogar ich verstehe:

```

system update requires rust - why?

```

----------

## Christian99

certbot braucht >=dev-python/cryptography-2.5.0[${PYTHON_USEDEP}], also nicht zwingend das neue cryptography.

evtl könnte dann (vorübergehend) das maskieren von >=dev-python/cryptography-37 helfen?

----------

## firefly

 *alexander_ro wrote:*   

> Doch doch das passt ... siehe oben da steht das es meine ARM Platinchen nicht können werden.
> 
> Warum sollte der Compiler auf dem ARM das plötzlich in 300MB können der muss auf beiden die selbe Arbeit machen?

 

Es ging bei meiner Annahme nicht darum dass das ganze gleich um den faktor 10+ weniger RAM brauchen wird sondern eher irgendwas zwischen 10-20% max.

Wenn wirklich nur 300MB RAM frei sind dann wäre es echt besser größer Pakte nicht auf dem gerät selbst bauen zu lassen. Oder wenn möglich bin packages nutzen (was es für rust gibt).

Oder halt was anderes nutzen.

In diesem thread wurden genügend alternativen zu certbot genannt.

Auf einigen system habe ich acme.sh verwendet statt certbot da die entwickler planen zukünftig für debian basierte distributionen certbot nur noch als snap package anbieten wollen.

Und wir debian auf unseren Server systemen nutzen.

Mir persönlich kann snap gestohlen bleiben. Ich bin kein Freund davon.

----------

## alexander_ro

 *Christian99 wrote:*   

> certbot braucht >=dev-python/cryptography-2.5.0[${PYTHON_USEDEP}], also nicht zwingend das neue cryptography.
> 
> evtl könnte dann (vorübergehend) das maskieren von >=dev-python/cryptography-37 helfen?

 

Indirekt habe ich das ja gemacht mit dem Maskieren von Rust dann sagt er das certbot nicht upgedatet wird.

----------

## firefly

 *alexander_ro wrote:*   

>  *Christian99 wrote:*   certbot braucht >=dev-python/cryptography-2.5.0[${PYTHON_USEDEP}], also nicht zwingend das neue cryptography.
> 
> evtl könnte dann (vorübergehend) das maskieren von >=dev-python/cryptography-37 helfen? 
> 
> Indirekt habe ich das ja gemacht mit dem Maskieren von Rust dann sagt er das certbot nicht upgedatet wird.

 

Lies mal genauer... Du müsstest alle versionen von >=dev-python/cryptography-37 maskieren...

Aber das bringt nur kurzfristig was.

Wie schon mehrmals gesagt hier helfen nur folgende Möglichkeiten:

1. Verwendung von dev-lang/rust-bin.

2. certbot nicht mehr verwenden und stattdessen eine der genannten alternativen

----------

## alexander_ro

Der macht kein Update wenn die Abhängigkeit nicht erfüllt ist. Mein Wunsch in der package.mask hat eindeutig Vorrang. Ich kann da kein Problem erkennen. Das es keine Lösung für die Ewigkeit ist ist ja Logisch.

Weiter oben habe ich bereits erwähnt das ich die Vorschläge Testen muss das dauert ein bisschen.

<Edit>

Das mod_md gibt es bei Gentoo aber noch nicht oder habe ich das nur nicht gefunden?

</Edit>

<Edit nochmal>

Weil es gerade erst wieder eins gab das gcc Update kann der kleine ARM problemlos machen.

</Edit nochmal>

----------

## alexander_ro

Habe ich das richtig verstanden: die DNS challange funktioniert nur wenn der DNS-Server eine wie auch immer geartete API unterstützt. Was der bind9 nicht tut weil das keine Standardlösung sondern Proprietär von Providern ist und damit mit meinem DNS-Server auch nicht geht?

----------

## Max Steel

 *alexander_ro wrote:*   

> Habe ich das richtig verstanden: die DNS challange funktioniert nur wenn der DNS-Server eine wie auch immer geartete API unterstützt. Was der bind9 nicht tut weil das keine Standardlösung sondern Proprietär von Providern ist und damit mit meinem DNS-Server auch nicht geht?

 

Üblicherweise werden solche DNS Challenges über DDNS (oder manuell, aber das will ja keiner) gelöst. Das ist per RFC standardisiert und bind unterstützt diesen. (zum Vergleich `ddns update` als Suchbegriff hilft da)

Ich hab das aber selber auch noch nicht eingerichtet. Und leider unterstützt Hetzner (wo meine Domain-DNS Rootzones liegen) die DDNS Updates auf ihrem Hetzner Cloud DNS Server nicht. Aber das ist ein anderes Thema.

----------

## alexander_ro

Bisher machte ich das mit dem Webroot manuell. Das es mit DNS auch manuell geht habe ich noch gar nicht gefunden. Bisher waren alle Beschreibungen nur mit dieser DNS-API.

Manuell würde auch gehen das muss man ja nur einmal machen. Die Aktualisierungen benutzen ja dann den vorhandenen Eintrag. Zumindest bei dem Webroot ist das so.

----------

## alexander_ro

Das mit dem DNS ist mühsam und umständlich und ob man irgendwelche Dubiosen Programme in den Zone Files herum schreiben lassen soll weiß ich auch nicht. Ist glaube ich keine gute Idee.

Ich habe das jetzt mal wieder mir Webroot so probiert:

```

acme.sh --log --test --issue --server letsencrypt --config-home /etc/Letsencrypt/ --webroot /hts-software.de --domain hts-software.de --domain www.hts-software.de

```

Das hat für eine Domain auch funktioniert. Bei dieser hier hat aber ein schlauer Mensch das .well-known gelöscht. Mein Problem ist jetzt das ich nur eine Fehlermeldung bekomme. Wie bekommt man denn wieder die neue Datei für diese Webroot Challange?

Der certbot hat mit --manual wenn man ein Zertifikat anfordert immer auch die Challange Datei neu angezeigt damit man die anlegen kann.

<Edit>

Irgendwie bekomme ich das nicht hin mit dem Webroot. Das geht nicht manuell und auch nicht automatisch. Das Script tut einfach gar nichts. Wenn es wenigstens ein Fehlermeldung gäbe wie "ich finde das scheiß verzeichnis nicht" oder ähnliches könnte man ja was machen aber so ...

Das manuelle DNS ist viel zu aufwändig. Weil man immer erst auf die öffentliche Verfügbarkeit warten muss. Automatisches DNS müsste ich erst irgendeine der API die das Script unterstützt nach Programmieren dann kann ich es aber gleich selber bauen.

</Edit>

----------

## l3u

Also ich benutze (u. a. auf meinem Raspberry Pi 1) auch den certbot.

Da habe ich rust-bin installiert, damit ist portage zufrieden und will keinen Rust-Compiler bauen.

Wie Webroot-Sache klappt vollkommen problemlos. Man muss halt den lokalen absoluten Pfad angeben, von dem aus der lokale HTTP-Server die jeweilige Seite ausliefert. Der Certbot legt dann da eine Datei ab, die der letsencrypt-Server findet, und damit ist bewiesen, dass man die Kontolle über die Domain hat.

Z. B.  hoste ich meine-domain.de auf meinem Server, der auszuliefernde Quelltext liegt unter /srv/http/meine-domain.de/ (liegt das, was du auslieferst, echt unter /hts-software.de?! Im Root-Verzeichnis direkt?). Dann legt der Certbot in /srv/http/meine-domain.de/.well-known/ was auch immer ab, der letsencrypt-Server checkt das, der certbot löscht es wieder und gut.

Wie gesagt: Klappt 1A bei mir, mit 8 Domains, lighttpd und der Web-Root-Challenge …

----------

## alexander_ro

Ja das ist mir bekannt das es mit dem certbot geht den habe ich vor dem Rust Zwang schon benutzt. Den benutze ich bisher auch immer noch. Das python Teil das Rust braucht habe ich nicht mehr aktuallisiert. Ich will Rust generell nicht auf dem Rechner haben. Nach dem Vorschlag hier weiter oben hatte ich die Binäre Version schon mal getestet das geht tatsächlich was ich nicht erwartet hatte. Aber warum eine Sourcecode Distribution verwenden wenn man so immer mehr Binär installieren muss?

Firefox, Thunderbird, Rust, qtwebengine (brauch ich für OpenShot), Desktop System (wegen Rust): Xfce, Gnome, KDE (nur einige Beispiele) ... das alles lässt sich nicht mehr Übersetzen wegen Speicher Problemen. Oder bau Zeiten von mehreren Tagen wenn man es mit einem Kern versucht um Speicher zu sparen. Woran erkennt man einen Entwickler der schlechte Arbeit leistet ... daran das er einen Rechner benutzt dessen Rechenleistung weit über dem Durchschnitt der Masse liegt. Die Merken gar nicht mehr was die für Ressourcen Fresser Programmieren und wie schlecht die Designs sind.

Ich finde das Neuerdings Moderne für jeden Mist eine neue Programmiersprache zu erfinden Unsinn. Weil die nichts besser machen Rust verkauft wie bei den Ami üblich auch nur wieder alte Konzepte mit neuem Namen. Rust kann mit Einschränkungen Speicher Probleme verhindern. Wer aber keine Einschränkungen will schaltet das einfach aus. Die Syntax ist grauenhaft Kryptisch und schwer lesbar beim IOCCC kann Rust mitmachen ohne das der Programmiere was besonders tun muss. Das wird Modern weil die OpenSource Macher wie die Mozis oder die Desktop Projekte heute Fette Finanzhilfen der Konzerne Einsacken. Damit habe heute die Entwickler alle Fette Maschinen und nicht mehr den Bedarf und die Notwendigkeit auf Ressourcen achten zu müssen. Das war einmal der Grund warum Linux erfunden wurde. KDE und Gnome sind in Sachen Bugs und Lahm sein mit Windows gleich gezogen. Wer nicht wie in Unternehmen üblich nach 2-3 Jahren Abschreibung die Rechner tauscht muss halt darauf verzichten. Der XFCE erreicht auch schon die Anfänge vom Erlahmung ... es leben die Müllberge das Einzige auf dem Planeten mit realem Wachstum.

----------

## l3u

Glaub mir, ich bin auch definitiv kein Freund von Rust und solchem Mist. Die sollten besser ordentlich Programmieren lernen und C++ benutzen :-P

Mich nervt das alles auch tierisch. Ich hab hier z. B. nen Ryzen 5 3600 (6 Kerne, 12 Threads) und 32 GB RAM. Inwiefern das weit über dem Durchschnitt liegt, weiß ich nicht, aber ist schon grad kein kleiner Rechner. Trotzdem ist das Bauen der allseits beliebten QtWebEngine eine Qual.

Den Trend zu immer mehr Speicherhunger und Millionen Zeilen zu übersetzendem Code finde ich bedenklich. HTML-Renderer sind mittlerweile komplexer als Betriebssysteme. Aber schneller geworden oder besser benutzbar geworden ist das Internet nicht, seitdem man es mit Doppel-ISDN und KHTML angeschaut hat.

----------

## alexander_ro

Gut zu wissen das ich nicht alleine die nicht mag ...  :Smile: 

Ja der Rechner ist sicher oberer Durchschnitt. Der Spruch soll ja auch nicht ganz Wörtliche genommen sein. Es geht darum das man die Leistung die man Anwendern die das Open  bei dem Source nutzen wollen im Rahmen halten muss weil sonst das Open Wertlos wird. Ist ja nicht so das wenn man die Software Modularer macht und bei den Modulen auf Binäre Abwärtskompatibilität achtet so nicht immer alle Millionen Zeilen an Sourcecode neu bauen muss deshalb auf schnellen Systemen schlechter laufen würde.

HTML ist ja jetzt auch ein Monströses Teil geworden. Die Konzerne haben sich immer aufgeregt das das W3C alles so Kompliziert macht. Was aber dann die Konzerne aus HTML gemacht haben wurde eine noch viel größere Katastrophe. Kein Wunder das es Komplex wird aber auch hier könnte Modulare Bauweise es verhindern Speicher und Rechenleistung recht Sinnfrei verbraucht werden. Aber auch auf schnellen Rechnern wäre das ein Gewinn weil dem Anwender mehr seiner Leistung übrig bleibt.

Ganz Dringen nötig wäre das man sich genau überlegt ob die neue Funktion überhaupt gebraucht wird. HTML enthält einige Dinge die man im Internet nie antrifft weil die offensichtlich keiner Braucht. Die sollte man dann auch irgendwann entsorgen oder noch besser erst gar nicht einbauen. Ist sicher nicht einfach einen guten Mittelweg zu finden aber dringend nötig.

<Edit>

Och jetzt geht es nicht mehr weil "dev-python/josepy" nur noch eine Version kennt die Rust erfordert wenn ich das Maskiere macht er gar keine Updates mehr. Ich werde mal schauen ob es viel Aufwand ist eine C++ Klasse dafür zu bauen. Die könnte ich dann auch in meiner Systemumgebung besser integrieren und bei meinem OpenSource Projekt hinzufügen. Nur habe ich bisher keine Verständlich Beschreibung gefunden wie das acme Protokoll funktioniert und was man unbedingt davon braucht. Das Dokument zu diesem Standard ist ein bisschen schwer lesbar. Ist vielleicht von euch einer mal über was leichter lesbares gestolpert?

</Edit>

----------

## Christian99

 *alexander_ro wrote:*   

> 
> 
> Och jetzt geht es nicht mehr weil "dev-python/josepy" nur noch eine Version kennt die Rust erfordert wenn ich das Maskiere macht er gar keine Updates mehr.
> 
> 

 

dafür gibts immer die Möglichkeit, ein lokales overlay einzurichten, in das man sich ebuilds für alte versionen kopieren kann, wenn man das braucht.

mit ACME selbst hab ich micht noch nicht intensiver beschäftigt, aber mir hilft es bei so was oft, wenn ich mir bereits vorhandene implementierungen anschaue. Evtl. haben die irgendwelche schalter, um debugging ausgaben anzumachen, oder man kann sie mit einem debugger anschauen.

Gehört nicht zum thema, aber mal so am rande: Vermutlich wird noch dieses Jahr rust im linux kernel freigegeben.

----------

## alexander_ro

Ja das war abzusehen nachdem man den Kernel Cheffee Mund tot machte mit einem Anti Kritik Dekret und Presse Macht das es mit dem Projekt abwärts geht. Die leben noch eine weile von ihrer alten Qualität. Dann landen die unter Industrieller Führung auf Micorsoft Level wie KDE und Gnome. Schade ...

Es wäre aber nicht OpenSource wenn es nicht eine Alternative gäbe.

Danke für die Hinweise ich werde mal schauen ob ich aus den Programmen was zur Funktionsweise heraus bekomme.

----------

## Christian99

https://www.phoronix.com/scan.php?page=news_item&px=GCC-Rust-SC-Approved

aber wenigstens brauchst du dann kein LLVM mehr für Rust.

----------

## schmidicom

 *Christian99 wrote:*   

> https://www.phoronix.com/scan.php?page=news_item&px=GCC-Rust-SC-Approved

 

Das dürfte dann vermutlich auch für die Verwendung von Rust im Linux-Kernel interessant sein.

----------

## alexander_ro

Ja ich hoffe die bekommen das auch so hin das man den Compiler mit endlichem Speicher und Zeitverbrauch auf Leistungsschwächeren System bauen kann so wie den für C/C++.

Wenn die Aussage der Kernelianer aus alten Zeiten noch gilt ist es eine zwingende Voraussetzung. Die hatten auch immer wieder Problem Kernel und Gcc aber es war immer das Ziel der der gcc den Kernel bauen kann. Es war ja auch der erste Compiler der überhaupt den Kernel bauen konnte.

----------

