|
|
|
|
|
|
|
| | Zitat von Traxer
ich bin nach wie vor der meinung, dass wir endlich mal ein vernünftiges(!) protokoll für den kram brauchen.
smb ist absoluter mist.
nfs kann nichts.
danach gibts dann nicht mehr viel. insbesondere wenn es cross platform funktionieren muss.
| |
Gabs nicht mal einen internettauglichen CIFS-Ersatz? Wenn der Scheiß nicht too chatty und fucking slow für alles wäre wärs ja ok.
|
|
|
|
|
|
|
|
|
|
|
Nachdem sie Bewiesen haben, dass sie Git --everything-is-local nicht verstanden haben, ihre Builddependencies unkontrolliert wuchern und daher jeder Entwickler den kompletten Windowsquellcode braucht und sie quasi ein Duennen-Subversion-Like-Layer geschrieben haben um die Unfaehigkeit von NTFS zu umgehen mit kleinen Dateien zu arbeiten...
Viel Vergnuegen. Git ist es aber nicht.
Und in der man-page haette gestanden, wie man nicht die komplette History mit auscheckt, Aber sowas lesen sie nicht 
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 25.05.2017 22:26]
|
|
|
|
|
|
|
|
|
| | Zitat von GarlandGreene
was hat ssh denn mit smb zu tun? scp ist doch eher ein ftp-Ersatz.
| |
Das ist uns bewusst. Das Feature "andere Server im Netzwerk automatisch finden und benuetzen" fehlt.
SSSH = Server-Secure-Shell
NFSSH = Network-File-Secure-Shell
Sowas halt 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von TheRealHawk
| | Zitat von Traxer
ich bin nach wie vor der meinung, dass wir endlich mal ein vernünftiges(!) protokoll für den kram brauchen.
smb ist absoluter mist.
nfs kann nichts.
danach gibts dann nicht mehr viel. insbesondere wenn es cross platform funktionieren muss.
| |
Gabs nicht mal einen internettauglichen CIFS-Ersatz? Wenn der Scheiß nicht too chatty und fucking slow für alles wäre wärs ja ok.
| |
ipfs?
|
|
|
|
|
|
|
|
|
|
|
| |
In 2014, the IPFS protocol took advantage of the Bitcoin blockchain protocol[...]
| |
BINGO!
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GarlandGreene
wer erlaubt denn sowas?
| |
intel und openipmi aka ipmitool.
der bmc ist von intel bzw deren zulieferer ami.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Nachdem sie Bewiesen haben, dass sie Git --everything-is-local nicht verstanden haben, ihre Builddependencies unkontrolliert wuchern und daher jeder Entwickler den kompletten Windowsquellcode braucht und sie quasi ein Duennen-Subversion-Like-Layer geschrieben haben um die Unfaehigkeit von NTFS zu umgehen mit kleinen Dateien zu arbeiten...
Viel Vergnuegen. Git ist es aber nicht.
Und in der man-page haette gestanden, wie man nicht die komplette History mit auscheckt, Aber sowas lesen sie nicht
| |
Also wie jede andere Firma eigentlich auch bei wirklich grossen Projekten. Hat wenig mit Verständnis zu tun.
Und du wirst die Legacy in einer solchen Codebase nicht einfach los, du Träumer. Wie willst du da einfach so mit über 20 Jahre anderer Technologie brechen in einem Schritt?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 26.05.2017 8:23]
|
|
|
|
|
|
|
|
|
Ich habe doch gerade gar kein GNU/Linux im Text gehabt...ach du beziehst dich nicht auf mich.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
Also wie jede andere Firma eigentlich auch bei wirklich grossen Projekten. Hat wenig mit Verständnis zu tun.
...
Und du wirst die Legacy in einer solchen Codebase nicht einfach los, du Träumer. Wie willst du da einfach so mit über 20 Jahre anderer Technologie brechen in einem Schritt?
| |
Stimmt. Bei mir sind es nur 15 Jahre und es ist nichts mehr zu retten. Ich traeume nicht, es ist ein Alptraum!
Und damit waeren wir bei geradezu glueckseligen Zustand von GNU/Linux, wir koennen unabhaengig am Kernel, LIBC, LIBSTDC++, X11/Wayland oder Systemd arbeiten. Andersherum ist es aber erstaunlich, wie viel Investition Microsoft betreibt um irgendwie einen Git/Bastard verwenden zu koennen, anstatt - in einem mehrere Jahre dauernden Projekt - den Zustand zu korregieren.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 26.05.2017 9:50]
|
|
|
|
|
|
|
|
|
Dein Projekt wird auch nichtmal einen Bruchteil so gross sein wie Windows.
Den Zustand korrigierst du nicht. Denkst du dir wirklich Microsoft hat nicht die Resourcen die entsprechenden Leute zu holen die ein gutes Konzept erarbeiten? Das hier ist das Resultat, ohne die Entwicklung maximalst auszubremsen. Gab auf Reddit auch einen Thread wo sich Mitarbeiter dazu geäussert haben. Neue Windowsentwicklungen werden so modular wie möglich gemacht, aber trotzdem ziehst du einen ganzen Schwall an legacy mit dir rum. Zumal Git jetzt auch nicht der Heilbringer in jeder Situation ist. Ich bin nichtmal so ein grosser Git Fan. Funktioniert, ist bei vielem aber genau so spackig wie anderes und die Bedienung lässt nunmal wirklich zu wünschen übrig. Da hätten sie sich ruhig mal eine Scheibe von Mercurial abschneiden können was CLI Interfaces angeht.
Und so modular ist das bei Linux jetzt auch wieder nicht. Bis du dir da alles zusammengefriemelt hast dauert es auch eine Weile. Klar, du kannst die einzelnen Teile ausschen, bringt dir aber auch nix. Ist ja jetzt auch nicht gerade so bequem wie paar Legosteine zusammenzustöpseln und ohne fertige Pakete eine übermässige Bitch. Ob das jetzt zusammen in einem Repo liegt oder nicht ist eine rein organisatorische Massnahme.
¤: Manchmal redest du dir den Scheiss echt zwanghaft schön, das ist kaum auszuhalten.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von SwissBushIndian am 26.05.2017 10:13]
|
|
|
|
|
|
|
|
|
Was willst du den schoenreden? Das ist alles riesig und komplex und das perfekte System gibt es nicht.
Seih froh, dass du Git hast und Mercurial kennst. Es koennte auch beide nicht geben! Und wenn wir lesen, dass die bei Microsoft zwangsweise den kompletten Quellcode bei jedem Systementwickler brauchen, dann haben die ein richtig unangenehmes Problem. Damit ist GNU/Linux immer noch eine unuebersichtliches System, immerhin reicht es dann aus mit dem jeweiligen Teil(en) zu Arbeiten. Vom Wissen ueber Konfigurationsoptionen und etliche Spezialfaellen befreit einem eine modulare Arbeitsgrundlage unter GNU/Linux auch nicht.
Microsoft sieht immer noch Vorteile in Git, obwohl sie die ganze Versionsverwaltung bis zu Unkenntlichkeit umbauen.
| |
¤: Manchmal redest du dir den Scheiss echt zwanghaft schön, das ist kaum auszuhalten.
| |
Und ich sehe bei dir eine negative Grundhaltung und beschwere mich nicht. Zum Haten ist die Hassthread da und ich koennte derzeit mal so richtig abkotzen. Vielleicht gehst du heute Nachmittag mal raus in die Sonne 
// edit
Hat eigentlich jemand in der Arbeitspraxis (nicht Github) wirklich ein Projekt angetroffen mit einem kurzen Anleitung der Abhaengigkeiten, welches man wirklich nur ausgecheckt und gebaut hat, das dann lief?
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 26.05.2017 10:41]
|
|
|
|
|
|
|
|
|
|
Bei dir klingt es einfach immer danach, als wären all das gelöste Probleme. Einfach Linux und Git nutzen und das Softwareengineering hat sich erledigt. Da muss man halt einfach mal klarstellen, dass dem nicht so ist. Das ist weder positiv, noch negativ, sondern einfach realistisch.
|
|
|
|
|
|
|
|
|
|
|
|
Indem du auf implizit gegeben Tatsachen - die jedem bewusst sind - herumreitest traegst du nicht zum Realismus bei. Du darfst den gesunden Menschenverstand hier annehmen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Hat eigentlich jemand in der Arbeitspraxis (nicht Github) wirklich ein Projekt angetroffen mit einem kurzen Anleitung der Abhaengigkeiten, welches man wirklich nur ausgecheckt und gebaut hat, das dann lief?
| |
Jo. AOSP. War selbst überrascht dass die fette Sau ohne Probleme durchgebaut hat ohne gnoch roß verhätschelt werden zu wollen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Du darfst den gesunden Menschenverstand hier annehmen.
| |
Da bin ich mir manchmal ehrlichgesagt nicht so sicher 
| | Zitat von hoschi
Hat eigentlich jemand in der Arbeitspraxis (nicht Github) wirklich ein Projekt angetroffen mit einem kurzen Anleitung der Abhaengigkeiten, welches man wirklich nur ausgecheckt und gebaut hat, das dann lief?
| |
Ja. War zwar ein ziemlicher Kampf, aber unsere Kerntechnologien integrieren sich inzwischen tatsächlich Nahtlos. Anleitung welche Repos in welcher Reihenfolge und welche dazugehörigen Scripts man ausführen muss und man hat die ganze Entwicklungsumgebung bei sich. Maven und Artifactory sei dank. Funktioniert sowohl unter Windows wie auch Linux, und auch für einzelne Teile des ganzen. Da hilft natürlich schonmal Java eine ganze Menge, aber auch, dass wir das von Anfang an so geplant haben. Da hatte zwar der Rest der CI Chain noch gefehlt und man musste seine Builds noch von Hand an die jeweilige Plattform einrichten, aber das hat sich dann nach und nach auch erledigt. Wenn man das dann einmal durchgelaufen hat kann man auch problemlos offline arbeiten wenn man Server + Projekt an dem man gerade arbeitet geclont respektive gebuildet hat.
War aber eine Menge Handarbeit und die eine oder andere Überstunde die ich nicht hätte leisten müssen. Lohnt sich aber.
¤: Die Scripts sind hauptsächlich für Leute, die zu dämlich sind ein paar wenige Kommandozeilenparameter zu übergeben (für Maven)... Von denen gibt es übermässig viele. Es braucht eigentlich nur auschecken + builden, vor dem Initialauscheck noch Maven richtig einrichten für Artifactory. That's it.
Und für die Serverumgebungen sind wir momentan am ausprobieren und paar Prototypen basteln ob sich Docker lohnen könnte für die lokale Entwicklung. Dann könnte man vielleicht für die einzelnen Teilgebiete noch spezifischere Dockerimages machen die dann kleiner sind und möglicherweise weniger Resourcen fressen. Da ich davon aber keine Ahnung und noch weniger Zeit habe könnte das noch dauern. Und ob das wirklich eine Lösung ist muss sich dann noch zeigen.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von SwissBushIndian am 26.05.2017 11:05]
|
|
|
|
|
|
|
|
|
|
Ich hab gehört das BitKeeper vom Design her besser sein soll als git. git ist halt schon ein eher ... stumpfes ... Tool. Das die UI aller Git-Tools im wesentlichen auf fünf Zwiebelschalen Faking beruht, macht es nicht besser, und Fehler von git recht schwer nachvollziehbar.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von SwissBushIndian
| |
Ein schönes Beispiel ist da z.B. sowas wie pdfTex. Versucht das mal aus den Sourcen zu bauen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
Was willst du den schoenreden? Das ist alles riesig und komplex und das perfekte System gibt es nicht.
Seih froh, dass du Git hast und Mercurial kennst. Es koennte auch beide nicht geben! Und wenn wir lesen, dass die bei Microsoft zwangsweise den kompletten Quellcode bei jedem Systementwickler brauchen, dann haben die ein richtig unangenehmes Problem. Damit ist GNU/Linux immer noch eine unuebersichtliches System, immerhin reicht es dann aus mit dem jeweiligen Teil(en) zu Arbeiten.
| |
das hat nichts mit schönreden zu tun, sondern mit der realität, dass nicht jedes popelige system ausschliesslich mit text basierten dateien arbeitet, die git wunderbar frisst.
schau dir mal bitte andere bereiche an. ich nehm jetzt mal zwei bereiche als beispiel.
der erste ist game development, da kannst du nicht anders als einen pervers grossen teil des repos lokal halten, weil du einfach nahezu alles aus dem repo brauchst um überhaupt irgendwas damit machen zu können.
du kannst nicht "nackt" an einer engine arbeiten, noch ohne engine an den assets. hier können die eigentlichen programm teile aka der source code durchaus auch mal eben aus fast ner million dateien bestehen. du hast hier aber auch das dämliche problem, dass du assets aka in DCC software erstellte sachen irgendwie revisionieren musst. speicher mal so ein "kleines" maya model oder eine 4x4k texture in 32-bit RGBA (ich rede hier bewusst gerade nicht von HDR texturen). die assets für selbst recht überschaubare produktionen wie z.b. so spiele wie doom werden da recht schnell mal 2-3 TB gross. da liegen dann nach wie vor gut 200-400 MB source code mit drin. der rest sind assets, ohne die du absolut gar nichts machen kannst ab nem gewissen punkt.
hier hast du dann schon das problem, dass du standard git einfach mal komplett in die tonne schmeissen kannst, weil du selbst die source assets in dein lokales repo klonen müsstest. das ist in der realität einfach mal komplett daneben und lahm.
ich rede hier auch nicht davon, dass git einfach nicht gut mit binärdateien kann oder mit grossen dateien.
beispiel zwei, ähnlich aber anders. VFX industrie.
du arbeitest ebenfalls mit mehreren hunderten MB an source code für diverse interne software packages die für diverse produktionen genutzt werden. da hast du auch einen wirr aus kuriosesten dependencies, weil die sachen teilweise sehr schnell und sehr speziell für projekte angepasst werden müssen um bestimmte effekte produziert werden können.
hier arbeitest du jetzt aber nicht mehr mit GB oder TB an assets, sondern je nach projekt einfach mal mit fast nem PB an assets files aus irgendwelchen DCC packages oder als render output.
das sind alles sachen die du in multiplen revisionen vorhalten willst / musst.
das sind ebenfalls mehr oder weniger die gleichen probleme, die MS da mit git hatte und für die sie lösungen gesucht haben. hier sind wie dann aber auch leider ganz schnell wieder bei dem üblichen problem vieler OSS sachen, die für ein ganz spezielles problem einer ganz speziellen firma oder person gebaut wurden und wo mal wieder niemand über den tellerrand geschaut hat. auch nach jahren nicht, in denen viele gerne gewechselt wären, aber es nicht können, weil deren wünsche und probleme konsequent ignoriert werden.
| | Zitat von hoschi
Microsoft sieht immer noch Vorteile in Git, obwohl sie die ganze Versionsverwaltung bis zu Unkenntlichkeit umbauen.
| |
da ist nichts zur unkenntlichkeit umgebaut, sie haben das system ledigllich an ein existierendes und ernstes problem angepasst, damit grosse projekte überhaupt damit vernünftig gefahren werden können.
du scheinst hier zu vergessen, dass git ursprünglich ausschliesslich für den linux kernel konzipiert wurde und nicht für irgendwelche anderen projekte.
das ur-git würdest du heute auch nicht verwenden wollen. die grössten änderungen an dem system kommen von diversen leuten, die das einfach an die realen bedürfnisse anpassen, auf die sie in anderen projekten stossen, weil die ursprünglich einfach nicht für git relevant waren.
das ist effektiv genau das, was OSS ist und sein sollte. die möglichkeit ein vorhandes "produkt" zu nehmen und es den eigenen anforderungen anzupassen, bzw. es dafür zu erweitern. dabei bzw. danach gibst du diese änderungen als dank wieder zurück an die community, die das dann nutzen kann, wenn sie will.
das ist und war der eigentliche gedanke hinter OSS und nichts poetterings friss-oder-stirb mentalität. das ist nämlich eher das, was MS jahrzehnte lang gemacht hat und sich gerade versucht davon zu lösen.
| | Zitat von hoschi
| |
¤: Manchmal redest du dir den Scheiss echt zwanghaft schön, das ist kaum auszuhalten.
| |
Und ich sehe bei dir eine negative Grundhaltung und beschwere mich nicht. Zum Haten ist die Hassthread da und ich koennte derzeit mal so richtig abkotzen. Vielleicht gehst du heute Nachmittag mal raus in die Sonne
| |
das ist keine "negative" grundhaltung sondern wirkt für mich einfach eher so, als wenn er die realität nicht aus den augen verliert wo diverse sachen leider einfach komplett anders laufen, als es schöne ideologen aller stallman gerne hätten.
du bist halt inzwischen leider nicht viel anders als die leute, die die apple religion gefressen haben. nur bei dir ists halt nicht, apple über alles und alles, wo apple drauf steht ist toll. bei dir ists alles was GNU ist ist das geilste überhaupt und keiner kann irgendwas besser als die GNU leute.
was in der realen welt einfach dämlich und gefährlich ist.
| | Zitat von hoschi
// edit
Hat eigentlich jemand in der Arbeitspraxis (nicht Github) wirklich ein Projekt angetroffen mit einem kurzen Anleitung der Abhaengigkeiten, welches man wirklich nur ausgecheckt und gebaut hat, das dann lief?
| |
ja, sogar sehr grosse sachen. hängt einfach davon ab, wie sauber die ersteller da mit ihrem dependency management sind. das hat nichts mit dem rcs zu tun.
coreclr hat bei mir immer sauber beim ersten versuch durchkompiliert. egal auf welchem system.
die UE 4 engine tut ebenfalls recht gut. ist aber nen komplett custom build system, weil viele andere einfach gewisse features und co nicht sauber können. damit sind wir dann aber wieder bei der frage ob custom lösungen so gut sind. es stellt sich aber heraus, dass die antwort ist "manchmal definitiv ja".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
@All:
Danke fuer den Input.
@Garland:
Stimmt auch was Garland schreibt, gerade wenn beachtet das Git fuer den Kernel geschaffen wurde. Spiele und ihre Engines sind ein gutes Gegenbeispiel. Ich moechte anmerken, dass es mir um Microsofts spezielles Eigenbau-Git ging, im Umkehrschluss haette Microsoft das nicht noetig, waere alles Modularer. Habe letzthin uebrigens den kleinen Fehler begangen einen Haufen Icons in Subversions mit einzuchecken. Hat eine Weile gebraucht, werde so schnell nichts mehr daran aendern.
Der Linux-Fanboy in mir leidet immer, wenn die GNOME-Shell mal wieder (heimlich) neu startet. Gut, selten und nicht schlimm. Was mich in letzter Zeit aber massiv anpisst, ist die Verbindungsverwaltung in SailfishOS. Zu grossen Teil in auf Qt und Mer aufgebaut und sie bekommen es nicht (wieder) hin zwischen WLAN und Mobilnetz sauber zu wechseln (Angeblich ein vermuteter Threadingbug in QtConnectionIrgendwas). Offenbar als Folge verschluckt XMPP undefiniert ausgehende Nachrichten. Funktioniert alles schoen, aber die Grundfunktionalitaet bricht weg. Habe so das Gefuehl, das sie bei Jolla ihren Technologiestack nicht im Griff haben. Und das hat mal zuverlaessig funktioniert. Ich habe mich schon mit einem iPhoneSE in der Hand bei Euronics erwischt.
Da haette man mit Canonical zusammen viel mehr bewegen koennen 
Vom Gefuehl her versuchen die nur noch SailfishOS auf alle moeglichen Maerkte zu werfen und auf irgendwas zu portieren, was man sowieso nicht kaufen kann.
|
|
[Dieser Beitrag wurde 8 mal editiert; zum letzten Mal von hoschi am 26.05.2017 11:57]
|
|
|
|
|
|
|
|
|
War das schon hier?
Ist ja ein recht typisches Muster, dass ein Fehler selten allein ist.
Kommenziere Kommentatur
| | | MsMpEng includes a full system x86 emulator that is used to execute any untrusted files that look like PE executables. The emulator runs as NT AUTHORITY\SYSTEM and isn't sandboxed. | |
lel
(Da wird bestimmt noch mehr drin stecken, x86-Emulation hat noch niemand nicht verkackt, siehe Xen-KVM-QEMU)
| | | * Command 0x0C allows allows you to parse arbitrary-attacker controlled RegularExpressions to Microsoft GRETA (a library abandoned since the early 2000s). This library is not safe to process untrusted Regex, a testcase that crashes MsMpEng attached. ¯\_(ツ)_/¯ | |
¯\_(ツ)_/¯
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 26.05.2017 18:12]
|
|
|
|
|
|
|
|
|
| | Zitat von hoschi
im Umkehrschluss haette Microsoft das nicht noetig, waere alles Modularer.
| |
Lustigerweise ist ja Windows eher ein Microkerneldesign, so im Kontrast zu Linux. Es ist also eher ein (historisch) organisatorisches als ein technisches Problem.
|
|
|
|
|
|
|
|
|
|
Aber. Warum?
@SwissBushIndian:
Du weisst doch, Monolithen sind halt unverwuestlich 
Ich frage mich, ob GNU Hurd jemals ausserhalb eines Emulators wirklich funktionsfaehig sein wird? Eher kommt da etwas ganz neues? Der Rest (Windows und MacOS) sind auch nur Hybriden.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 29.05.2017 10:11]
|
|
|
|
|
|
|
|
|
Wo ist NT denn ein Mikrokernel im technischen Sinne?
WDDM, ja, ein bisschen. Sonst fällt mir da nicht so viel ein, ist doch eigentlich eher ein Monolith mit Modulen?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 29.05.2017 10:12]
|
|
|
|
|
|
|
|
|
Offiziell wird es als ein Hybrid aus Microkernel und Monolith deklariert, genauso wie Darwin bei MacOS.
// edit
Ich faende es wirklich toll, wenn sich Kernel-Hotpatching durchsetzen wuerde. Dann kann Greg von mir aus alle drei Tage (tut er das nicht jetzt schon?) ein Kernelupdate herausgeben.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 29.05.2017 10:14]
|
|
|
|
|
|
|
|
|
Offiziell =>
| | | NT-based Windows is classified as a hybrid kernel (or a macrokernel[2]) rather than a monolithic kernel because the emulation subsystems run in user-mode server processes, rather than in kernel mode as on a monolithic kernel, and further because of the large number of design goals which resemble design goals of Mach (in particular the separation of OS personalities from a general kernel design). | |
= Marketing.
|
|
|
|
|
|
|
|
|
|
|
Emulation Subsystems 
Klingt fuer mich eher nach HAL oder Legacysachen?
|
|
|
|
|
|
|
|
|
|
|
Dinge wie Win32, WOW64, früher POSIX und SFU.
e: Und natürlich WSL, wobei das iirc kein reines Subsystem ist.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 29.05.2017 11:43]
|
|
|
|
|
|
|
|
|
Alter, dieses letsencrypt ist mir irgendwie nicht so ganz klar.
Hab auf meinem Webserver alle Weiterleitungen und Alias eingerichtet und kann auch auf das gewünschte Verzeichnis für die Challenge zugreifen, aber das dehydrated Skript kriegt es nicht hin und wirft nen 403.
Mal am Wochenende dran setzen.
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 // 0x23 ( const int MAX_POST = 30 * 100; // 0x23 ) |
