Stratum 0 - Benutzerbeiträge [de]

Spacegate

2012-04-03T15:19:26Z

Cbounce: /* Alternativvorschlag: */

{{Projekt
|verantwortlich={{Benutzer|DooMMasteR}}
|status=aktiv
|interessenten=[[Benutzer:Daniel Bohrer|Daniel Bohrer]], [[Benutzer:Hellfyre|Hellfyre]]
}}
== Idee ==

Das Spacegate sollte nach Möglichkeit von jedem Mitglied und ggf. auch kurzfristig autorisierten Gast geöffnet werden.
Das äußere Spacegate lässt sich bisher einfach per Handy öffnen, ist zwar nicht toll, abe rklappt.

Für das Innere Gate wäre eine raffinierter Lösung erstrebenswert.

Zur Verwirklichung sind 2 Hürden zu überwinden.
#Authetifizierung der Person die Zugang verlangt
#ermöglichen des Zuganges

=== Authorisierung ===
Wir sollten zum Autorisieren des Zuganges ein System haben, welches folgende Bedingungen erfüllt:
*Günstig
*Sicher
*Flexibel
*PrivacyProtecting
*Available

Das Problem ist dabei größer als es Zunächst erscheint.

Mechanische Schlüssel scheiden aus, da sie 1. recht teuer sind und 2. bei Verlust zu Problemen in der Autorisierungskette anderer Schlüssel führen.

IP-Basierende Systeme scheiden aus, da sie den Betrieb eines IP-Fähigen Endgerätes voraussetzen und auch recht hohen Implementierungsaufwand auf verschiedenen Plattformen mit sich brächte.

RFID ist im Grunde sehr viel versprechend aber birgt eine gewisse Privacyproblematik in sich, die ID des Tags und damit die Traceability des Users.

Dennoch erscheint RFID als der Beste Ansatz, denn:
*recht günstig
*lässt sich vielfältig einsetzen (man könnte ungenutzte Bereiche von Karten offen für andere Nutzungen lassen)
*flexibel ggf. kann ein Nutzer seine eigene Karte mitbringen und Beschreiben lassen
*weit verbreitet, gerade 13,xxMHz Tags
*ließe sich auch in Smartphones implementieren
*einzelne Karten können bei Verlust de-autorisiert werden

bleibt die privacy Problematik durch die ID, dazu: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1508247 (z.B. aus dem Uninetz lesbar)

Falls der Link oben nicht funktioniert (IEEE Seite hat merkwürdige Cookie-Magie), hier der DOI [http://dx.doi.org/10.1109/DEXA.2005.28 10.1109/DEXA.2005.28]

Lösung bisher: KEINE -.-
Das Problem wäre beim Einsatz eines aktiven Tags nicht vorhanden

==== Alternativvorschlag: ====
* Aktiver Key auf LED-Basis
** Protokoll basierend auf http://www.merl.com/papers/docs/TR2003-35.pdf
** Hardware: umbauen einer fertigen LED-Keychain im einstelligen EUR-Bereich mit einem 8pin-uC (1EUR) und nem Widerstand
** Security: Einfachste Möglichkeit ist, eine ID, einen fixen Schlüssel der Tür und einen des Tokens direkt im uC zu speichern. Die Tür "authed" sich also beim Schlüssel, er spuckt seine ID und Schlüssel zurück. Wenn man das ganze dann noch "richtig" sicher machen will, versucht man entweder ne Hashfunktion mit auf den uC zu quetschen (http://www.das-labor.org/wiki/AVR-Crypto-Lib), oder baut einen SHA-256-chip mit ein (http://de.mouser.com/Search/Refine.aspx?Keyword=AT88SA100S).
** Nachteile:
*** noch ungetestet
*** Frickelarbeit mit der Keychain
** Vorteile
*** LED-Funktion bleibt erhalten
*** kein Problem mit der Traceability
*** Sicher (je nach Aufwand)
*** Ich finds cool ;)

Ich wollte sowas in der Art immer mal bauen, wenn ich mich selber mal hingesetzt habe und nen Prototyp läuft, berichte ich vielleicht nochmal.
--[[Benutzer:Cbounce|Cbounce]] 17:09, 3. Apr. 2012 (CEST)

=== Oeffnung ===

Ich habe einen Tueroeffner, den man vermutlich oben in den Tuerrahmen einbauen kann. Bei Anlegen von 12V gibt das frei. habs allerdings nie ausprobiert. Ich brings mal mit demnaechst --[[Benutzer:Valodim|Valodim]] 20:04, 30. Mär. 2012 (CEST)

:Liegt jetzt übrigens hier im Lounge-Regal. --[[Benutzer:Daniel Bohrer|Daniel Bohrer]] 22:24, 2. Apr. 2012 (CEST)

== Alte Diskussion ==
''…wurde vorher auf [[Open/Close-Monitor]] geführt, hier der Vollständigkeit halber hinverschoben --[[Benutzer:Daniel Bohrer|Daniel Bohrer]] 12:17, 31. Mär. 2012 (CEST)''

Falls der Space sich hinreichend entwickelt hat, kann über weitergehende Maßnahmen nachgedacht werden. Im µCCC z.B. wird die Türschließung durch ein [https://wiki.muc.ccc.de/luftschleuse Zugangssystem per SSH] gesteuert.

=== Verbesserung der Klingel ===
…wenn wir grad schonmal am Klingelhacken sind. Im Chat kam der Vorschlag nach einer optischen Klingel (Blinken o.ä.). Alternativ, falls alle Spaceinsassen gerade schlafen:

[11:59:51] <rohieb> dann die sofas mit drahtgeflecht versehen und die klingel stromschläge draufgeben lassen?
[12:00:04] <tommie-lie> schon besser
[12:00:04] <neobechstein> :D
[12:00:06] <neobechstein> rohieb: +1

Alternativ wäre zu überlegen, ob man [[ZombiePoet]] beibringt, Klingelevents im IRC zu verkünden. Bzw, wenn an der Tür später eh ein µC/ARM oder ähnliches mit Netzwerk hängt, könnte man dort direkt einen IRC-Bot implementieren ;-) (ZombiePoet läuft ja auf einem externen Server, das würde dann nur noch eine Schicht mehr hinzufügen)

[[Kategorie:Infrastruktur]]

Spacegate

2012-04-03T15:19:03Z

Cbounce: /* Alternativvorschlag: */

{{Projekt
|verantwortlich={{Benutzer|DooMMasteR}}
|status=aktiv
|interessenten=[[Benutzer:Daniel Bohrer|Daniel Bohrer]], [[Benutzer:Hellfyre|Hellfyre]]
}}
== Idee ==

Das Spacegate sollte nach Möglichkeit von jedem Mitglied und ggf. auch kurzfristig autorisierten Gast geöffnet werden.
Das äußere Spacegate lässt sich bisher einfach per Handy öffnen, ist zwar nicht toll, abe rklappt.

Für das Innere Gate wäre eine raffinierter Lösung erstrebenswert.

Zur Verwirklichung sind 2 Hürden zu überwinden.
#Authetifizierung der Person die Zugang verlangt
#ermöglichen des Zuganges

=== Authorisierung ===
Wir sollten zum Autorisieren des Zuganges ein System haben, welches folgende Bedingungen erfüllt:
*Günstig
*Sicher
*Flexibel
*PrivacyProtecting
*Available

Das Problem ist dabei größer als es Zunächst erscheint.

Mechanische Schlüssel scheiden aus, da sie 1. recht teuer sind und 2. bei Verlust zu Problemen in der Autorisierungskette anderer Schlüssel führen.

IP-Basierende Systeme scheiden aus, da sie den Betrieb eines IP-Fähigen Endgerätes voraussetzen und auch recht hohen Implementierungsaufwand auf verschiedenen Plattformen mit sich brächte.

RFID ist im Grunde sehr viel versprechend aber birgt eine gewisse Privacyproblematik in sich, die ID des Tags und damit die Traceability des Users.

Dennoch erscheint RFID als der Beste Ansatz, denn:
*recht günstig
*lässt sich vielfältig einsetzen (man könnte ungenutzte Bereiche von Karten offen für andere Nutzungen lassen)
*flexibel ggf. kann ein Nutzer seine eigene Karte mitbringen und Beschreiben lassen
*weit verbreitet, gerade 13,xxMHz Tags
*ließe sich auch in Smartphones implementieren
*einzelne Karten können bei Verlust de-autorisiert werden

bleibt die privacy Problematik durch die ID, dazu: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1508247 (z.B. aus dem Uninetz lesbar)

Falls der Link oben nicht funktioniert (IEEE Seite hat merkwürdige Cookie-Magie), hier der DOI [http://dx.doi.org/10.1109/DEXA.2005.28 10.1109/DEXA.2005.28]

Lösung bisher: KEINE -.-
Das Problem wäre beim Einsatz eines aktiven Tags nicht vorhanden

==== Alternativvorschlag: ====
* Aktiver Key auf LED-Basis
** Protokoll basierend auf http://www.merl.com/papers/docs/TR2003-35.pdf
** Hardware: umbauen einer fertigen LED-Keychain im einstelligen EUR-Bereich mit einem 8pin-uC (1EUR) und nem Widerstand
** Security: Einfachste Möglichkeit ist, eine ID, einen fixen Schlüssel der Tür und einen des Tokens direkt im uC zu speichern. Die Tür "authed" sich also beim Schlüssel, er spuckt seine ID und Schlüssel zurück. Wenn man das ganze dann noch "richtig" sicher machen will, versucht man entweder ne Hashfunktion mit auf den uC zu quetschen (http://www.das-labor.org/wiki/AVR-Crypto-Lib), oder baut einen SHA-512-chip mit ein (http://de.mouser.com/Search/Refine.aspx?Keyword=AT88SA100S).
** Nachteile:
*** noch ungetestet
*** Frickelarbeit mit der Keychain
** Vorteile
*** LED-Funktion bleibt erhalten
*** kein Problem mit der Traceability
*** Sicher (je nach Aufwand)
*** Ich finds cool ;)

Ich wollte sowas in der Art immer mal bauen, wenn ich mich selber mal hingesetzt habe und nen Prototyp läuft, berichte ich vielleicht nochmal.
--[[Benutzer:Cbounce|Cbounce]] 17:09, 3. Apr. 2012 (CEST)

=== Oeffnung ===

Ich habe einen Tueroeffner, den man vermutlich oben in den Tuerrahmen einbauen kann. Bei Anlegen von 12V gibt das frei. habs allerdings nie ausprobiert. Ich brings mal mit demnaechst --[[Benutzer:Valodim|Valodim]] 20:04, 30. Mär. 2012 (CEST)

:Liegt jetzt übrigens hier im Lounge-Regal. --[[Benutzer:Daniel Bohrer|Daniel Bohrer]] 22:24, 2. Apr. 2012 (CEST)

== Alte Diskussion ==
''…wurde vorher auf [[Open/Close-Monitor]] geführt, hier der Vollständigkeit halber hinverschoben --[[Benutzer:Daniel Bohrer|Daniel Bohrer]] 12:17, 31. Mär. 2012 (CEST)''

Falls der Space sich hinreichend entwickelt hat, kann über weitergehende Maßnahmen nachgedacht werden. Im µCCC z.B. wird die Türschließung durch ein [https://wiki.muc.ccc.de/luftschleuse Zugangssystem per SSH] gesteuert.

=== Verbesserung der Klingel ===
…wenn wir grad schonmal am Klingelhacken sind. Im Chat kam der Vorschlag nach einer optischen Klingel (Blinken o.ä.). Alternativ, falls alle Spaceinsassen gerade schlafen:

[11:59:51] <rohieb> dann die sofas mit drahtgeflecht versehen und die klingel stromschläge draufgeben lassen?
[12:00:04] <tommie-lie> schon besser
[12:00:04] <neobechstein> :D
[12:00:06] <neobechstein> rohieb: +1

Alternativ wäre zu überlegen, ob man [[ZombiePoet]] beibringt, Klingelevents im IRC zu verkünden. Bzw, wenn an der Tür später eh ein µC/ARM oder ähnliches mit Netzwerk hängt, könnte man dort direkt einen IRC-Bot implementieren ;-) (ZombiePoet läuft ja auf einem externen Server, das würde dann nur noch eine Schicht mehr hinzufügen)

[[Kategorie:Infrastruktur]]

Spacegate

2012-04-03T15:09:22Z

Cbounce: /* Authorisierung */ LED-Auth eingefügt

{{Projekt
|verantwortlich={{Benutzer|DooMMasteR}}
|status=aktiv
|interessenten=[[Benutzer:Daniel Bohrer|Daniel Bohrer]], [[Benutzer:Hellfyre|Hellfyre]]
}}
== Idee ==

Das Spacegate sollte nach Möglichkeit von jedem Mitglied und ggf. auch kurzfristig autorisierten Gast geöffnet werden.
Das äußere Spacegate lässt sich bisher einfach per Handy öffnen, ist zwar nicht toll, abe rklappt.

Für das Innere Gate wäre eine raffinierter Lösung erstrebenswert.

Zur Verwirklichung sind 2 Hürden zu überwinden.
#Authetifizierung der Person die Zugang verlangt
#ermöglichen des Zuganges

=== Authorisierung ===
Wir sollten zum Autorisieren des Zuganges ein System haben, welches folgende Bedingungen erfüllt:
*Günstig
*Sicher
*Flexibel
*PrivacyProtecting
*Available

Das Problem ist dabei größer als es Zunächst erscheint.

Mechanische Schlüssel scheiden aus, da sie 1. recht teuer sind und 2. bei Verlust zu Problemen in der Autorisierungskette anderer Schlüssel führen.

IP-Basierende Systeme scheiden aus, da sie den Betrieb eines IP-Fähigen Endgerätes voraussetzen und auch recht hohen Implementierungsaufwand auf verschiedenen Plattformen mit sich brächte.

RFID ist im Grunde sehr viel versprechend aber birgt eine gewisse Privacyproblematik in sich, die ID des Tags und damit die Traceability des Users.

Dennoch erscheint RFID als der Beste Ansatz, denn:
*recht günstig
*lässt sich vielfältig einsetzen (man könnte ungenutzte Bereiche von Karten offen für andere Nutzungen lassen)
*flexibel ggf. kann ein Nutzer seine eigene Karte mitbringen und Beschreiben lassen
*weit verbreitet, gerade 13,xxMHz Tags
*ließe sich auch in Smartphones implementieren
*einzelne Karten können bei Verlust de-autorisiert werden

bleibt die privacy Problematik durch die ID, dazu: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1508247 (z.B. aus dem Uninetz lesbar)

Falls der Link oben nicht funktioniert (IEEE Seite hat merkwürdige Cookie-Magie), hier der DOI [http://dx.doi.org/10.1109/DEXA.2005.28 10.1109/DEXA.2005.28]

Lösung bisher: KEINE -.-
Das Problem wäre beim Einsatz eines aktiven Tags nicht vorhanden

== Alternativvorschlag: ==
* Aktiver Key auf LED-Basis
** Protokoll basierend auf http://www.merl.com/papers/docs/TR2003-35.pdf
** Hardware: umbauen einer fertigen LED-Keychain im einstelligen EUR-Bereich mit einem 8pin-uC (1EUR) und nem Widerstand
** Security: Einfachste Möglichkeit ist, eine ID, einen fixen Schlüssel der Tür und einen des Tokens direkt im uC zu speichern. Die Tür "authed" sich also beim Schlüssel, er spuckt seine ID und Schlüssel zurück. Wenn man das ganze dann noch "richtig" sicher machen will, versucht man entweder ne Hashfunktion mit auf den uC zu quetschen (http://www.das-labor.org/wiki/AVR-Crypto-Lib), oder baut einen SHA-512-chip mit ein (wieder 1-2 EUR).
** Nachteile:
*** noch ungetestet
*** Frickelarbeit mit der Keychain
** Vorteile
*** LED-Funktion bleibt erhalten
*** kein Problem mit der Traceability
*** Sicher (je nach Aufwand)
*** Ich finds cool ;)

Ich wollte sowas in der Art immer mal bauen, wenn ich mich selber mal hingesetzt habe und nen Prototyp läuft, berichte ich vielleicht nochmal.
--[[Benutzer:Cbounce|Cbounce]] 17:09, 3. Apr. 2012 (CEST)

=== Oeffnung ===

Ich habe einen Tueroeffner, den man vermutlich oben in den Tuerrahmen einbauen kann. Bei Anlegen von 12V gibt das frei. habs allerdings nie ausprobiert. Ich brings mal mit demnaechst --[[Benutzer:Valodim|Valodim]] 20:04, 30. Mär. 2012 (CEST)

:Liegt jetzt übrigens hier im Lounge-Regal. --[[Benutzer:Daniel Bohrer|Daniel Bohrer]] 22:24, 2. Apr. 2012 (CEST)

== Alte Diskussion ==
''…wurde vorher auf [[Open/Close-Monitor]] geführt, hier der Vollständigkeit halber hinverschoben --[[Benutzer:Daniel Bohrer|Daniel Bohrer]] 12:17, 31. Mär. 2012 (CEST)''

Falls der Space sich hinreichend entwickelt hat, kann über weitergehende Maßnahmen nachgedacht werden. Im µCCC z.B. wird die Türschließung durch ein [https://wiki.muc.ccc.de/luftschleuse Zugangssystem per SSH] gesteuert.

=== Verbesserung der Klingel ===
…wenn wir grad schonmal am Klingelhacken sind. Im Chat kam der Vorschlag nach einer optischen Klingel (Blinken o.ä.). Alternativ, falls alle Spaceinsassen gerade schlafen:

[11:59:51] <rohieb> dann die sofas mit drahtgeflecht versehen und die klingel stromschläge draufgeben lassen?
[12:00:04] <tommie-lie> schon besser
[12:00:04] <neobechstein> :D
[12:00:06] <neobechstein> rohieb: +1

Alternativ wäre zu überlegen, ob man [[ZombiePoet]] beibringt, Klingelevents im IRC zu verkünden. Bzw, wenn an der Tür später eh ein µC/ARM oder ähnliches mit Netzwerk hängt, könnte man dort direkt einen IRC-Bot implementieren ;-) (ZombiePoet läuft ja auf einem externen Server, das würde dann nur noch eine Schicht mehr hinzufügen)

[[Kategorie:Infrastruktur]]

Keysigning-Party 2012-03-08

2012-03-07T13:07:21Z

Cbounce: /* Teilnehmer */

Eine [[wikipedia:de:Keysigning-Party|Keysigning-Party]] ist eine Party
(nie mit Musik, fast immer ohne Essen, nur selten mit Mädels ;-)),
die dazu dient, PGP-Keys gegenseitig zu unterschreiben,
um damit ein Web of Trust aufzubauen.

== Termin ==

1. PGP Party im Space am '''Donnerstag, 8. März, ab 20h'''

'''Achtung:''' An diesem Tag fahren aufgrund von Streik keine öffentlichen Verkehrsmittel! Bitte weicht auf Auto/Fahrrad/Füße/… aus, um zum Hackerspace zu kommen.

== Teilnehmer ==

{| class="prettytable sortable"
! Name
! IRC Nick
! E-Mail der Main-ID
! [Link zu] Key-ID
! Bemerkung
|-
| Sven Guckes
| SvenG
| pgp@guckes.net
| [http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x57F77F09 57F77F09]
| nur heute im space
|-
| Roland Hieber
| rohieb
| rohieb kringelzeichen rohieb.name
| [http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xB2413C66DD2C3FEA DD2C3FEA]
|-
| Jan Lübbe
| …
| jluebbe@lasnet.de
| [http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x8A838BE4D8480F2E D8480F2E] [http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xBBF68F03E8F37941 E8F37941]
|-
| Vincent Breitmoser
| …
| valodim@mugenguild.com
| [http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x751661D4 751661D4]
|-
| Heinrich Schmidt
| …
| heinrich@ktrask.de
| [http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x93A27B87 93A27B87]
| (ich komme erst gegen 22:30)
|-
| Bjørn Bürger
| …
| b.buerger@penguin.de
| TBD
|-
| Stephen Röttger
| …
| stephen.roettger@zero-entropy.de
| [http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xEF2C49F0 EF2C49F0]
|-
| Steffen Arntz
| DooMMasteR
| winrootkit@googlemail.com
| [http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x62B9DCFF6624C1A2 6624C1A2]
| neuer key, da alter vermurkst -.-
|-
| Jan-Henrik Kluth
| jh
| jhkluth@gmx.de
| [http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x731B144F 731B144F]
|
|-
| Matthias Uschok
| hellfyre
| matthias [klammeraffe] uschok.de
| [http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x23A1F8A4 23A1F8A4]
|
|-
| Johannes Starosta
| joke
| johannes.starosta [klammeräffchen] schunternet [PUNKT].de
| [http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x15ABA8EF83918D3B|0x83918D3B] [http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x87BB173686E86D0F|0x86E86D0F]
| weiß noch nicht, wie ich hinkomme
|-
| Sandra Hesse
| Silberwoelfin
| shesse[at]lavabit.com
|[http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xE2808686 E2808686]
|-
| Carsten Bohnens
| cbounce
| c.bohnens@tu-bs.de
|[http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x91BE0EC225CB0CE0 25CB0CE0]
|-
| $NAME
| $IRC
| $MAIL
| $KEY
| $REMARK
|}

== Mitbringen ==
* Den '''Ausdruck aller Schlüssel''', die signiert werden sollen, mit den eingetragenen Prüfsummen
** Mit GPG geht das über die Befehlszeile <tt>gpg --list-secret --fingerprint [Schlüssel-ID]</tt> (wobei die Schlüssel-ID auch weggelassen werden kann).
* Ein gültiges '''Ausweisdokument''' (Personalausweis, Reisepass, Führerschein)
* Einen '''Stift''' zum Schreiben und Abhaken der Fingerprints und IDs
* Mehrere '''Schlüsselstreifen''' mit Fingerprints zum Verteilen

== Ablauf ==

* 20:00 Begrüßung
* 20:15 Überprüfung der Anwesenheit
* 20:20 Feststellen bzw. Vergleichen der Prüfsummen (falls noch jemand eine Summary macht)
* 20:25 Vergleichen der Fingerprints
* 20:30 Modalitaeten festlegen: Unterschriften zuschicken oder hochladen?

falls mehr als 10 Leute teilnehmen:
* In einer Reihe aufstellen; ggf. Leute mit ausgedruckten Fingerprints integrieren.
* Identitäten überprüfen, dh Vorzeigen und kontrollieren der Ausweise.

Kür:
* kurze Vorträge (5min) über relevante Software
* Installation und Konfiguration von GnuPG

== Links ==

* Wikipedia: [http://de.wikipedia.org/wiki/Keysigning-Party Key Signing Party (de)]
* Wikipedia: [http://en.wikipedia.org/wiki/Keysigning-Party Key Signing Party (en)]
* [http://alfie.ist.org/projects/gpg-party/gpg-party.de.html GnuPGP Party Howto] v1.1.0 [2003-11-26] von Gerfried Fuchs
* [http://www.biglumber.com/ BigLumber] - Website fuer die Koordination von KSPs ([http://biglumber.com/x/web?ev=22269 dieses Event])

== ToDo ==

* Links hinzufügen zu den üblichen Seiten, also zur Idee und zu Verfahrensweisen.
* Erstellung eines Relationsgraphen, zB [https://www.linuxtag.org/2011/uploads/media/ksp-lt2k11_20110509_0920.svg KSP Linuxtage 2011]

[[Kategorie:Termine]]
[[Kategorie:Community]]

Benutzer:Cbounce

2011-08-15T16:23:06Z

Cbounce: Die Seite wurde neu angelegt: „XMPP: b0unce beim server jabber in der domain ccc in deutschland“

XMPP: b0unce beim server jabber in der domain ccc in deutschland

Diskussion:Workshops

2011-08-15T16:20:03Z

Cbounce: /* Zum Workshop "Mikrocontroller-Kurs" */ --> ags

== Zum Workshop "Musik machen" ==

@Wansti: Würde da auch sowas wie Effektgeräte selbst basteln reinfallen? Fänd ich recht interessant --[[Benutzer:Henning|Henning]] 12:30, 31. Mai 2011 (UTC)

Gute Idee, nur sind meine Fähigkeiten dazu nicht workshoptauglich. Eigentlich gehört der Eintrag auch eher in die Kategorie "Projekte" als Workshops, aber man kann ja beides machen.

== Zum Workshop "Mikrocontroller-Kurs" ==

Es gibt an der TU regelmäßige Mikrocontroller-Kurse: http://www.ags.tu-bs.de/?id=e.lab:kurse
Die Jungs da sind auch hinreichend gutartig drauf, da könnte man mal überlegen sich ggf. mit denen abzusprechen,
im besten Fall kommt ne Kooperation mit Leuten die viel Ahnung von dem Kram haben und ein bisschen Werbung für den Hackerspace bei raus.
Im schlimmsten Fall passiert nichts. --[[Benutzer:Henning|Henning]] 12:55, 15. Aug. 2011 (UTC)

Ich bin einer der Organisatoren/Betreuer besagter Kurse in der ags, und wollte mich dazu gleich einmal äußern =) Prinzipiell spricht nix gegen Know-How weitergeben, aber man muss ehrlich sagen, dass die Kurse für uns auch nicht ganz einfach zu stemmen sind, und, zumindest was Material angeht, von der Uni mitfinanziert werden (Geld für die Arbeit bekommen wir allerdings nicht!). Da wir als VEREIN auch recht exklusiv Studenten ansprechen, sehe ich einen "offiziellen" Kurs eher weniger. Was aber nicht heißt, dass Einzelpersonen (mich eingeschlossen) nicht bereit wären, einen Workshop bei Euch zumindest zu unterstützen, wenn nicht auch zu geben, falls Interesse besteht und bei uns die Zeit da ist. --[[Benutzer:Cbounce|Cbounce]] 16:20, 15. Aug. 2011 (UTC)