social.stefan-muenz.de

Search

Items tagged with: BIldung

Error 404: Es ist beschämend, was nach großen Ankündigungen am Ende draus wird. Die Umsetzung der schlechten Kopie meiner Bundeszentrale für digitale #Medienbildung lässt weiter auf sich warten. Es braucht #Bildung gegen #Desinformation.
#Medienkompetenz
https://netzpolitik.org/2021/digitalkompetenz-was-wurde-eigentlich-aus-der-bundeszentrale-fuer-digitale-aufklaerung-frau-baer/
 
Hört sich an wie ein Witz, scheint aber keiner zu sein. "die Programmiererinnen und Programmierer müssen an Computern in der #Hochschule arbeiten – man kann ja nicht jedem eine SAP-Lizenz auf den heimischen Rechner spielen."

https://www.spiegel.de/panorama/bildung/mittweida-studierende-organisieren-impfaktion-an-der-hochschule-a-c1f1465e-bff2-4df6-b7b4-e59c60ecf2ba

#OER #Bildung #FreieSoftware #SAP
 
Free and Open Source Software Conference (FrOSCon) - Call for Papers https://www.froscon.de/cfp/cfpapers/

Normalerweise in Sankt Augustin, in 2021 online.

Thematische Schwerpunkte
- #Betriebssysteme
- #Entwicklung
- #Administration
- #Sicherheit
- #RechtlicheFragen
- #Desktop
- #Bildung
- #GIS
- #Cloud

#FOSS #SanktAugustin #Bonn #FrOSCon
 
Der Catch 22 unseres Bildungssystems:
Wir brauchen eine Schule mit dem Ziel, Kinder zu starken Persönlichkeiten zu bilden.
Aber um eine solche Schule zu schaffen, braucht es starke Persönlichkeiten.
#Bildung
 
Das Bundesministerium für Bildung und Forschung hat Ende April 2021 den ersten Schritt für den Aufbau einer Nationalen Bildungsplattform unternommen.
Ein piqd von Anja C. Wagner https://www.piqd.de/zukunft-der-arbeit/die-nationale-bildungsplattform-als-digitales-grossprojekt und der Artikel auf haufe.de: https://www.haufe.de/personal/hr-management/nationale-bildungsplattform_80_542294.html
#Bildung
 
Bei allem anderen sollten wir nicht die #Bildung vergessen, damit eines Tages Kinder in eine Schule gehen, die sie zu starken Persönlichkeiten macht, statt sie zu brechen und ihre Potentiale in vielen Fällen eher zu vernichten.
Anja C. Wagner setzt sich professionell und vor dem Hintergrund modernster wissenschaftlicher Kenntnisse und technischer Möglichkeiten schon lange dafür ein. Ich bin sicher, ihr Buch dazu ist klasse!
Zertifikate
 

down with english lessons!


here in berlin-neukölln gentrification is rampant. wildest capitalism on the loose. and the epitome of capitalism are english lessons, obviously ...

#berlin #bildung #neukölln

Bild/Foto
 
Ein guter Beitrag über Herrschaft und das, was sie aufrecht erhält:
"Entstanden im aufsteigenden Bürgertum, hat er sich #Bildung als ein unhinterfragtes Konzept über die Gesellschaft gelegt. Bis heute sind für „akademische“ Kinder die Chancen zigfach höher, an eine Uni zu kommen und dort Erfolg zu haben. Es sind nicht alle „ihres Glückes Schmied“. Das ist Ideologie, denn wir leben nicht in einer herrschaftsfreien Gesellschaft, in der es egal wäre, woher man kommt."
 
Anja C. Wagner in einem piqd zu Hochschul- #Bildung:
"In der "Kultur der Digitalität" steckt gehöriges emanzipatorisches Potenzial. Dieses gilt es zu heben - und dafür braucht es mehr asynchrone, akademische Vernetzung und lebenslangen Austausch. Stattdessen gilt es, die standardisierten Curricula abzuschaffen, die stromlinienförmige Menschen generieren."
 

#Sicherheit in der Luca-App und von #OpenSource allgemein


Durch einen Post von @Michael Vogel wurde ich auf ein Problem im Quellcode der Luca-App aufmerksam: https://pod.geraspora.de/posts/13446160

Die zwei kritischen Code-Stücke sind für das Testen zuständig und man findet sie hier: https://gitlab.com/lucaapp/android/-/blob/master/Luca/app/src/main/java/de/culture4life/luca/ui/registration/RegistrationViewModel.java

Teil 1:
public boolean isUsingTestingCredentials() {
return Objects.equals(firstName.getValue(), "John")
&& Objects.equals(lastName.getValue(), "Doe")
&& Objects.equals(phoneNumber.getValue(), "+4900000000000")
&& Objects.equals(email.getValue(), "john.doe@gmail.com");
}

Teil 2:
boolean isValidPhoneNumber(String phoneNumberString) {
if (isUsingTestingCredentials()) {
return true;
}
try {...

Als Hackerin mit Codex will ich mich darüber nicht nur lustig machen sondern erklären worin das Problem liegt und wie man es beheben kann.

Sicherheitsverständnis bei Open-Source

Ein weit verbreitete Fehleinschätzung ist, dass Open-Source sicherer ist als geheimer proprietärer Quellcode. Niemand außer dem Besitzer kann geheimen Quellcode prüfen und deswegen können Fehler jahrelang unbemerkt bleiben und nur von Eingeweihten ausgenutzt werden. So kann man im geheimen Quellcode problemlos Hintertüren und andere Schweinereien verstecken.

Open-Source oder freier Quellcode kann von jedem eingesehen werden und so ist es schwieriger dort Hintertüren zu verstecken. Diese Schwierigkeit macht den offenen Quellecode schon mal ein bisschen sicherer. Dann muss dieser Quellcode aber immer noch getestet, überprüft und kontrolliert werden. Geschieht dies nicht und alle vertrauen nur blind auf die Sicherheit dann ist das sehr fahrlässig. Es gibt leider Beispiele wo offensichtliche Fehler im frei zugänglichen Quellcode jahrelang übersehen wurden - siehe: Heartbleed - https://de.wikipedia.org/wiki/Heartbleed

Jetzt muss man aber auch die Philosophie von freier Software verstehen und die wird nirgendwo an der Universität gelehrt. Die muss man sich per Selbststudium im Internet beibringen. Wenn jeder in den Quellcode schauen kann und er danach immer noch sicher ist, dann habe ich echte Sicherheit (immer vorausgesetzt, dass Experten auch drauf geschaut haben). Das heißt natürlich, dass ich nichts in den Quellcode schreiben darf was man später ausnutzen kann (weil dies würde die Sicherheit schwächen).

Leider lernt man an der Universität oder Ausbildung sogut wie nichts über Sicherheit, die schon beim Design der Software ansetzt. Dies sind relativ neue Forschungen und die Ausbildungskräfte bilden sich nicht gut genug fort als das sie darüber Kenntnisse hätten. Für Wirtschaftsinformatiker scheint es wichtiger zu sein, dass sie profitabel sind und nicht sicheren Quellcode schreiben (blöder Kapitalismus).

Was ist hier das Problem?

Am oben gezeigten Quellcode sieht man, dass getestet wird. So was nennt man Test-Driven-Development und das ist zunächst etwas Gutes. Der Quellcode wird vor dem "Build" also dem zusammenbauen als fertige App zunächst automatisiert getestet und wenn ein Test fehlschlägt wird der "Build" abgebrochen, sodass der Fehler korrigiert werden muss. Der Fehler kann wenn er durch den Test erkannt wird also nicht beim Endbenutzer auftauchen.

Wie man aber in Teil 2 oben sieht kann man mit den Testdaten Prüfungen in der App umgehen und dadurch mehr Rechte erhalten. Noch viel schlimmer ist, dass wir in Teil 2 sehen, das der "try"-Teil erst nach der Prüfung auf Testdaten startet. "Try" ist für die Fehlerbehandlung zuständig und das bedeutet ich kann mit Testdaten die App in einen undefinierten Zustand bringen, weil es keine Fehlerbehandlung gibt. Diese undefinierten Zustände können Hacker häufig für Exploits ausnutzen.

Insgesamt also alles sehr schlecht!

Wie kann ich das besser machen?

1) Compilerflags - Mit Compilerflags kann ich verhindern, das bestimmte Programmteile in der produktiven App landen. Vereinfacht gesagt ich baue mir eine Testversion und wenn die funktioniert dann baue ich mir eine Produktivversion wo die Testfunktionen nicht enthalten sind. Großer Nachteil dieser Methode ist, das Programmierer gelegentlich vergessen, die Testfunktionen richtig rauszulöschen mit den Flags weil sie zu sehr unter Druck stehen und dann Fehler machen. So ist es häufiger schon passiert, dass unbeabsichtigt Testfunktionen doch im Produktivsystem gelandet sind. Ein weiteres Problem ist wenn Fehler nicht in der Testversion auftreten aber im Produktivsystem weil es anders gebaut wurde. Dann sind wahrscheinlich irgendwo die Compilerflags falsch gesetzt worden. Ein Fehler den man dann niemals machen darf, der aber schon passiert ist, ist, dass dann einfach die Testversion ausgeliefert wird in der Hoffnung, dass das niemand merkt.

2) Testflags verwenden - In der Testumgebung wird über die Konfiguration ein bestimmtes Flag gesetzt, sodass die Software weiß, dass sie im Testmodus ist. Nachteil ist, dass bösartige Hacker diese Flag auch in der Produktivumgebung setzen könnten.

3) So Testen, dass es keinen Unterschied macht (beste Lösung). Warum im Testsystem nicht mit anonymisierten oder pseudonymisierten Daten so testen wie unter echten Bedingungen? Meistens macht das etwas mehr Aufwand aber dafür hat man die Tests unter Echtbedingungen gemacht was den höchsten Wert hat. Keine Flags oder Funktionen im Quellcode die ausgenutzt werden könnten.
#luca #software #testen #test #sicherheit #problem #bildung #entwicklung #verstädnis #lernen #hack #hacking #app #smartphone #gesundheit #corona #programm
 

#Sicherheit in der Luca-App und von #OpenSource allgemein


Durch einen Post von @Michael Vogel wurde ich auf ein Problem im Quellcode der Luca-App aufmerksam: https://pod.geraspora.de/posts/13446160

Die zwei kritischen Code-Stücke sind für das Testen zuständig und man findet sie hier: https://gitlab.com/lucaapp/android/-/blob/master/Luca/app/src/main/java/de/culture4life/luca/ui/registration/RegistrationViewModel.java

Teil 1:
public boolean isUsingTestingCredentials() {
return Objects.equals(firstName.getValue(), "John")
&& Objects.equals(lastName.getValue(), "Doe")
&& Objects.equals(phoneNumber.getValue(), "+4900000000000")
&& Objects.equals(email.getValue(), "john.doe@gmail.com");
}

Teil 2:
boolean isValidPhoneNumber(String phoneNumberString) {
if (isUsingTestingCredentials()) {
return true;
}
try {...

Als Hackerin mit Codex will ich mich darüber nicht nur lustig machen sondern erklären worin das Problem liegt und wie man es beheben kann.

Sicherheitsverständnis bei Open-Source

Ein weit verbreitete Fehleinschätzung ist, dass Open-Source sicherer ist als geheimer proprietärer Quellcode. Niemand außer dem Besitzer kann geheimen Quellcode prüfen und deswegen können Fehler jahrelang unbemerkt bleiben und nur von Eingeweihten ausgenutzt werden. So kann man im geheimen Quellcode problemlos Hintertüren und andere Schweinereien verstecken.

Open-Source oder freier Quellcode kann von jedem eingesehen werden und so ist es schwieriger dort Hintertüren zu verstecken. Diese Schwierigkeit macht den offenen Quellecode schon mal ein bisschen sicherer. Dann muss dieser Quellcode aber immer noch getestet, überprüft und kontrolliert werden. Geschieht dies nicht und alle vertrauen nur blind auf die Sicherheit dann ist das sehr fahrlässig. Es gibt leider Beispiele wo offensichtliche Fehler im frei zugänglichen Quellcode jahrelang übersehen wurden - siehe: Heartbleed - https://de.wikipedia.org/wiki/Heartbleed

Jetzt muss man aber auch die Philosophie von freier Software verstehen und die wird nirgendwo an der Universität gelehrt. Die muss man sich per Selbststudium im Internet beibringen. Wenn jeder in den Quellcode schauen kann und er danach immer noch sicher ist, dann habe ich echte Sicherheit (immer vorausgesetzt, dass Experten auch drauf geschaut haben). Das heißt natürlich, dass ich nichts in den Quellcode schreiben darf was man später ausnutzen kann (weil dies würde die Sicherheit schwächen).

Leider lernt man an der Universität oder Ausbildung sogut wie nichts über Sicherheit, die schon beim Design der Software ansetzt. Dies sind relativ neue Forschungen und die Ausbildungskräfte bilden sich nicht gut genug fort als das sie darüber Kenntnisse hätten. Für Wirtschaftsinformatiker scheint es wichtiger zu sein, dass sie profitabel sind und nicht sicheren Quellcode schreiben (blöder Kapitalismus).

Was ist hier das Problem?

Am oben gezeigten Quellcode sieht man, dass getestet wird. So was nennt man Test-Driven-Development und das ist zunächst etwas Gutes. Der Quellcode wird vor dem "Build" also dem zusammenbauen als fertige App zunächst automatisiert getestet und wenn ein Test fehlschlägt wird der "Build" abgebrochen, sodass der Fehler korrigiert werden muss. Der Fehler kann wenn er durch den Test erkannt wird also nicht beim Endbenutzer auftauchen.

Wie man aber in Teil 2 oben sieht kann man mit den Testdaten Prüfungen in der App umgehen und dadurch mehr Rechte erhalten. Noch viel schlimmer ist, dass wir in Teil 2 sehen, das der "try"-Teil erst nach der Prüfung auf Testdaten startet. "Try" ist für die Fehlerbehandlung zuständig und das bedeutet ich kann mit Testdaten die App in einen undefinierten Zustand bringen, weil es keine Fehlerbehandlung gibt. Diese undefinierten Zustände können Hacker häufig für Exploits ausnutzen.

Insgesamt also alles sehr schlecht!

Wie kann ich das besser machen?

1) Compilerflags - Mit Compilerflags kann ich verhindern, das bestimmte Programmteile in der produktiven App landen. Vereinfacht gesagt ich baue mir eine Testversion und wenn die funktioniert dann baue ich mir eine Produktivversion wo die Testfunktionen nicht enthalten sind. Großer Nachteil dieser Methode ist, das Programmierer gelegentlich vergessen, die Testfunktionen richtig rauszulöschen mit den Flags weil sie zu sehr unter Druck stehen und dann Fehler machen. So ist es häufiger schon passiert, dass unbeabsichtigt Testfunktionen doch im Produktivsystem gelandet sind. Ein weiteres Problem ist wenn Fehler nicht in der Testversion auftreten aber im Produktivsystem weil es anders gebaut wurde. Dann sind wahrscheinlich irgendwo die Compilerflags falsch gesetzt worden. Ein Fehler den man dann niemals machen darf, der aber schon passiert ist, ist, dass dann einfach die Testversion ausgeliefert wird in der Hoffnung, dass das niemand merkt.

2) Testflags verwenden - In der Testumgebung wird über die Konfiguration ein bestimmtes Flag gesetzt, sodass die Software weiß, dass sie im Testmodus ist. Nachteil ist, dass bösartige Hacker diese Flag auch in der Produktivumgebung setzen könnten.

3) So Testen, dass es keinen Unterschied macht (beste Lösung). Warum im Testsystem nicht mit anonymisierten oder pseudonymisierten Daten so testen wie unter echten Bedingungen? Meistens macht das etwas mehr Aufwand aber dafür hat man die Tests unter Echtbedingungen gemacht was den höchsten Wert hat. Keine Flags oder Funktionen im Quellcode die ausgenutzt werden könnten.
#luca #software #testen #test #sicherheit #problem #bildung #entwicklung #verstädnis #lernen #hack #hacking #app #smartphone #gesundheit #corona #programm
 

#Sicherheit in der Luca-App und von #OpenSource allgemein


Durch einen Post von @Michael Vogel wurde ich auf ein Problem im Quellcode der Luca-App aufmerksam: https://pod.geraspora.de/posts/13446160

Die zwei kritischen Code-Stücke sind für das Testen zuständig und man findet sie hier: https://gitlab.com/lucaapp/android/-/blob/master/Luca/app/src/main/java/de/culture4life/luca/ui/registration/RegistrationViewModel.java

Teil 1:
public boolean isUsingTestingCredentials() {
return Objects.equals(firstName.getValue(), "John")
&& Objects.equals(lastName.getValue(), "Doe")
&& Objects.equals(phoneNumber.getValue(), "+4900000000000")
&& Objects.equals(email.getValue(), "john.doe@gmail.com");
}

Teil 2:
boolean isValidPhoneNumber(String phoneNumberString) {
if (isUsingTestingCredentials()) {
return true;
}
try {...

Als Hackerin mit Codex will ich mich darüber nicht nur lustig machen sondern erklären worin das Problem liegt und wie man es beheben kann.

Sicherheitsverständnis bei Open-Source

Ein weit verbreitete Fehleinschätzung ist, dass Open-Source sicherer ist als geheimer proprietärer Quellcode. Niemand außer dem Besitzer kann geheimen Quellcode prüfen und deswegen können Fehler jahrelang unbemerkt bleiben und nur von Eingeweihten ausgenutzt werden. So kann man im geheimen Quellcode problemlos Hintertüren und andere Schweinereien verstecken.

Open-Source oder freier Quellcode kann von jedem eingesehen werden und so ist es schwieriger dort Hintertüren zu verstecken. Diese Schwierigkeit macht den offenen Quellecode schon mal ein bisschen sicherer. Dann muss dieser Quellcode aber immer noch getestet, überprüft und kontrolliert werden. Geschieht dies nicht und alle vertrauen nur blind auf die Sicherheit dann ist das sehr fahrlässig. Es gibt leider Beispiele wo offensichtliche Fehler im frei zugänglichen Quellcode jahrelang übersehen wurden - siehe: Heartbleed - https://de.wikipedia.org/wiki/Heartbleed

Jetzt muss man aber auch die Philosophie von freier Software verstehen und die wird nirgendwo an der Universität gelehrt. Die muss man sich per Selbststudium im Internet beibringen. Wenn jeder in den Quellcode schauen kann und er danach immer noch sicher ist, dann habe ich echte Sicherheit (immer vorausgesetzt, dass Experten auch drauf geschaut haben). Das heißt natürlich, dass ich nichts in den Quellcode schreiben darf was man später ausnutzen kann (weil dies würde die Sicherheit schwächen).

Leider lernt man an der Universität oder Ausbildung sogut wie nichts über Sicherheit, die schon beim Design der Software ansetzt. Dies sind relativ neue Forschungen und die Ausbildungskräfte bilden sich nicht gut genug fort als das sie darüber Kenntnisse hätten. Für Wirtschaftsinformatiker scheint es wichtiger zu sein, dass sie profitabel sind und nicht sicheren Quellcode schreiben (blöder Kapitalismus).

Was ist hier das Problem?

Am oben gezeigten Quellcode sieht man, dass getestet wird. So was nennt man Test-Driven-Development und das ist zunächst etwas Gutes. Der Quellcode wird vor dem "Build" also dem zusammenbauen als fertige App zunächst automatisiert getestet und wenn ein Test fehlschlägt wird der "Build" abgebrochen, sodass der Fehler korrigiert werden muss. Der Fehler kann wenn er durch den Test erkannt wird also nicht beim Endbenutzer auftauchen.

Wie man aber in Teil 2 oben sieht kann man mit den Testdaten Prüfungen in der App umgehen und dadurch mehr Rechte erhalten. Noch viel schlimmer ist, dass wir in Teil 2 sehen, das der "try"-Teil erst nach der Prüfung auf Testdaten startet. "Try" ist für die Fehlerbehandlung zuständig und das bedeutet ich kann mit Testdaten die App in einen undefinierten Zustand bringen, weil es keine Fehlerbehandlung gibt. Diese undefinierten Zustände können Hacker häufig für Exploits ausnutzen.

Insgesamt also alles sehr schlecht!

Wie kann ich das besser machen?

1) Compilerflags - Mit Compilerflags kann ich verhindern, das bestimmte Programmteile in der produktiven App landen. Vereinfacht gesagt ich baue mir eine Testversion und wenn die funktioniert dann baue ich mir eine Produktivversion wo die Testfunktionen nicht enthalten sind. Großer Nachteil dieser Methode ist, das Programmierer gelegentlich vergessen, die Testfunktionen richtig rauszulöschen mit den Flags weil sie zu sehr unter Druck stehen und dann Fehler machen. So ist es häufiger schon passiert, dass unbeabsichtigt Testfunktionen doch im Produktivsystem gelandet sind. Ein weiteres Problem ist wenn Fehler nicht in der Testversion auftreten aber im Produktivsystem weil es anders gebaut wurde. Dann sind wahrscheinlich irgendwo die Compilerflags falsch gesetzt worden. Ein Fehler den man dann niemals machen darf, der aber schon passiert ist, ist, dass dann einfach die Testversion ausgeliefert wird in der Hoffnung, dass das niemand merkt.

2) Testflags verwenden - In der Testumgebung wird über die Konfiguration ein bestimmtes Flag gesetzt, sodass die Software weiß, dass sie im Testmodus ist. Nachteil ist, dass bösartige Hacker diese Flag auch in der Produktivumgebung setzen könnten.

3) So Testen, dass es keinen Unterschied macht (beste Lösung). Warum im Testsystem nicht mit anonymisierten oder pseudonymisierten Daten so testen wie unter echten Bedingungen? Meistens macht das etwas mehr Aufwand aber dafür hat man die Tests unter Echtbedingungen gemacht was den höchsten Wert hat. Keine Flags oder Funktionen im Quellcode die ausgenutzt werden könnten.
#luca #software #testen #test #sicherheit #problem #bildung #entwicklung #verstädnis #lernen #hack #hacking #app #smartphone #gesundheit #corona #programm
 
ACHTUNG, Lehrer*innen:
Macht mal was nützliches!
Das Corona-Virus ist ein unerbittlicher Lehrmeister: Nie waren Fake News gefährlicher als jetzt. In einem neuen kostenlosen Workshop "Unterrichtseinheit News/Fake News" erklärt der ehemalige Spiegel-Redakteur Schnibben grundlegendes journalistisches Handwerk und wie Jugendliche lernen, Fake News zu erkennen.
#Medien #Bildung
 
Wir müssen lange vernachlässigte Diskussionsstränge zu #Bildung, #Justizvollzug und #Psychiatrie wieder aufnehmen.
 
Bürgerinitiativen in der #Bildung
Eine ganz hervorragende Diskussion, mit wertvollen Hinweisen zu Homepages, IT-Initiativen etc., vorerst nur als Audio.
Ein Glück, dass ich nicht der einzige bin, der an unserem Bildungssystem verzweifelt, vielleicht schaffen wir es irgendwann doch, was daran zu ändern.
 
Ich habs noch nicht gelesen, aber wichtig wärs:
Neuausrichtung des Bildungssystems anhand von #Inklusion
#Bildung
 
German survey on education in Germany under corona conditions.

Bent Freiwald von #Krautreporter möchte wissen, egal, ob ihr Eltern seid, als Lehrer:innen arbeitet oder noch zur Schule geht: Was habt ihr nach zwölf Monaten #Corona über Schule, Lernen und #Bildung gelernt?
 
Hoffnung auf qualifizierte Weiterbildung nur in etablierten Kreisen
"Das korporatistische dt Bildungsmodell wird denjenigen, die in der Krise jetzt aus ihren unsicheren Jobs fliegen, kaum helfen. Es geht einzig und alleine um die Wettbewerbsfähigkeit der erfolgreichen Unternehmen."
piqd von Anja C. Wagner zum forschungsindustriellen Komplex ...
#BIldung
 
#Bundeszentrale für politische #Bildung

Unabhängigkeit bedroht


Auf Bitten des Bundesinnenministeriums änderte die #bpb einen #Teaser im #Linksextremismus - Dossier. Der #taz liegt nun der Wortlaut dieser „Bitte“ vor.

https://taz.de/Bundeszentrale-fuer-politische-Bildung/!5750736/

#taz #Demokratie #Unabhängigkeit #Rechtsextremismus
 
#Bundeszentrale für politische #Bildung

Unabhängigkeit bedroht


Auf Bitten des Bundesinnenministeriums änderte die #bpb einen #Teaser im #Linksextremismus - Dossier. Der #taz liegt nun der Wortlaut dieser „Bitte“ vor.

https://taz.de/Bundeszentrale-fuer-politische-Bildung/!5750736/

#taz #Demokratie #Unabhängigkeit #Rechtsextremismus
 
"Schulleiter warnt: #Schule wird möglicherweise unorganisierbar"
Im Interesse unserer Schülerinnen und Schüler wäre das angesichts des aktuellen Schulsystems in Deutschland das beste, was passieren könnte. #Bildung
 
"Schulleiter warnt: #Schule wird möglicherweise unorganisierbar"
Im Interesse unserer Schülerinnen und Schüler wäre das angesichts des aktuellen Schulsystems in Deutschland das beste, was passieren könnte. #Bildung
 
"Akademische Mittel­schicht definiert sich durch ihre Ausbildungs­erfolge, u jedes Mal, wenn sie dem Land wieder erklärt, dass es mehr #Bildung braucht, sagt sie im Grunde nur: Die Ungleichheit ist nicht der Fehler des Systems. Sie ist dein Fehler." (piqd)
 
RT @Report_Antisem@twitter.com

Gerade stellt die Beratungsstelle SABRA der Jüdischen Gemeinde #Düsseldorf den "virtuelle Methodenkoffer gegen #Antisemitismus MALMAD" vor. Dieser ist ein Werkzeug für Lehrer*innen bzw. Pädagog*innen.
#Bildung #Schulen #Schule

Link zum Koffer: https://www.malmad.de/
 
"Lernraum" heißt das Portal, das Coderinnen aus dem Umfeld des Chaos Computer Clubs programmiert haben. Ein zuverlässiger digitaler Ort, der es Berliner Schulen ermöglichen soll, Schülerinnen sicher und datenschutzgerecht zu versammeln und zu unterrichten (piqd).
Jetzt bräuchten die nur noch eine funktionierende Internet-Verbindung...
#Bildung #Digitalisierung
 
Later posts Earlier posts