Beiträge von gandro

Zitat von TAL

Frage ist nur in wie weit die Software unter Windows/Linux dir das ausliest und entsprechend anzeigt. Da würde ich ja primär letzeres preferenzieren.

Da die Mute-Taste zwar Hardware stumm macht und kein Toogle ist, sondern auch nach mehrfachem drücken stumm bleibt und da die Firmware den Tastendruck an sich weiterleitet, kann bei einem ordentlichen Betriebsystem problemlos den Software-Regler bei Tastedruck ebenfalls muten, so dass Software- und Hardware gemuted und man das auch im OS sieht.

Zitat von oreissig

eigentlich hätte ich gern alles in software, denn dass man das mute nich sieht im OS hat mich schonmal ziemlich angearscht weil ich das nicht wusste und kein sound kam und es eben nirgends angezeigt wird.

Zumindest bei meinem T20 (dem letzten Gerät was ich mit HW-Regler hatte) konnte man den Status durchaus von einem OSD anzeigen lassen, der Wert lässt sich auf Anfrage aus der Firmware auslesen.

Bei den neueren ist nur noch Software-Regler - bis auf Mute, das ist zumindest bei der Xx00er-Serie immer noch Hardware (verwenden alle den gleichen Chip wie mein X200). Glaube bei Xx10 und Xx20 auch noch.

Ich wusste das mit der Apache Foundation nicht, von daher hat OOo auch eine Zukunft, wie du dem Therad hier durchaus entnehmen kannst.

Aber da wird in den nächsten 1-2 Jahren erstmal noch wenig passieren, bis dahin kann man gut zu LibreOffice greifen.

Mein Gegenargument ist: Copyleft ist Wunschdenken.

Annahme: Ein Unternehmen hat kein wirkliches Interesse daran, ihre Modifikationen ebenfalls open-source zu machen.

Dann gibt es zwei Fälle:
1. Das Unternehmen verzichtet darauf ein Produkt auf GPL-Basis zu machen. Davon profitiert niemand: Weder die Firma, noch ihre Kunden, noch die GPL-Programmierer.
2. Das Unternehmen arbeitet trotzdem mit einer GPL-Basis, stellt die ganzen Patches dann auf einer Seite irgendwo ins Netz - ohne Toolkits oder Compiler damit man wirklich damit was anfangen könnte. Beispiel: Amazon Kindle Firmware.

GPL-lizenzierte Software bringt dem GPL-Programmierer keinen Vorteil, während es gleichzeitig andere OpenSource-Projekte benachteiligt: Andere OpenSource-Programmierer mit Nicht-GPL-Kompatiblen-Lizenzen den GPL-Code nicht verwenden dürfen, obwohl sie ihn offen stellen würden, aber nicht GPL machen wollen.

Fazit: Die GPL stört parasitäre Firmen nicht, während sie gleichzeitig andere OpenSource-Entwickler behindert.

Eben. Und dein Argument war implizit ja, dass die AL wie BSD nicht Copyleft ist und daher Firmen nicht gezwungen sind, eigene Änderungen oder Verwendungen des Codes öffentlich zu machen.

Ach Mist. Jetzt wollte ich einen tollen Flame über die Philosophie BSD-License vs. GPL auslösen, aber da müsst ihr schon mitmachen.

Zitat von mrshadowtux

Ja, dir ist auch bewusst dass Openoffice dadurch in die Hände von IBM kommt, die es für ihr kommerzielles Lotus Symphony nutzen wollen?

Wo ist das Problem?

Apache Foundation garantiert ein Weiterleben des Projektes unabhängig von Firmeninteressen.

Wenn IBM zusätzlich meint da Features reinzupacken die sie nicht quelloffen veröffentlichen können/wollen/dürfen, wo ist das Problem?

Nur weil IBM nicht gezwungen wird den Code den sie schreiben zu veröffentlichen, heisst das nicht, dass sie den Code auch schreiben würden, wenn sie es müssten.

Zitat von TAL

Dir ist schon bewusst das Oracle das ganze an die Apache Software Foundation übergeben will?

Cool. Wusste ich gar nicht. Wenn das passiert, dann hat OpenOffice durchaus Zukunft, denn die Apache Foundation legt enorm Wert auf garantierte Unabhängigkeit und Zukunftssicherheit.

Könnte mir vorstellen, dass es dann auch einen Merge geben könnte. Aber das wird sich zeigen, erstmal muss OOo ein Apache Projekt werden, das ist schwieriger als es klingt.

Zur Zeit spielts keine Rolle, die Software ist praktisch die gleiche. Wobei LibreOffice einiges aus dem Go-OO-Fork übernommen hat und damit 2-3 nicht-so-wichtige Features mehr hat.

In Zukunft wird wohl LibreOffice die Wahl sein, einfach weil da die Entwicklermehrheit sitzt und daher da wohl mehr passieren wird.

Nachtrag: Passiert ist der Fork weil einige Leute unzufrieden waren mit Oracles Produktepolitik und wollten das Projekt auf eigene Beine stellen. Die haben dann eine Stiftung gegründet und Oracle liebt gefragt, ob sie die Marke kriegen. Haben sie nicht, drum heisst der Fork jetzt LibreOffice.

GVFS ist die Dateisystemverwaltung von GNOME. SynCE klingt mir nach Synchronisierung für Windows CE.

Da findet man für Debian in der Tat nichts. Das einzige Repository was ich gefunden habe ist hier:
Mark's SynCE Corner

Da existiert in der Paketliste ein Paket namens "synce-gnomevfs". Kann sein dass das veraltete GNOME bei Debian noch GnomeVFS anstatt gvfs verwendet.

Moderator-Log zeigt zumindest, wer die Originale geschlossen hat. Werd' bei der Person mal nachfragen.

Hm? Für Firmen gibts seit jeher das MSI-Paketsystem, für Privatkunden gibts mit Windows 8 dann einen AppStore. Passt doch.

o_O was soll das?

Im einen oder anderen Thread stehen durchaus relevante Informationen.

Zitat von Ultra10

unter den jetzigen Umständen ist Googles Wissen nicht gefährlich, und das wird es auch nie sein.

Da machst du es dir zu einfach. Mir fallen mehrere Szenarien ein, in denen ich als Benutzer auf Google vertrauen muss, sorgfältig mit meinen Daten umzugehen:

1. Das genannte Beispiel mit Zugriff auf den E-Mail-Account. Wer in mein E-Mail-Postfach gelangt, hat Zugriff auf mein PayPal-Account, diverse Datenbanken diverser Webseiten wo ich Admin-Rechte, Zugriff auf alles was mein Studium betrifft. Ein simpler Kleinkrimineller ohne persönliche Absichten könnte da schon richtig schön Unsinn anstellen.

2. Das betrifft die meisten hier nicht, aber spätestens seit der Ägyptischen Revolution und Wikileaks ist klar, dass das Internet als Kommunkationsplattform durchaus enormen Einfluss auf Politik haben kann. Verwende ich als Aktivist einen von Internetdienst, dann muss ich dem Anbieter vertrauen, dass er nicht vorauseilenden Gehorsam ausübt, sondern erst auf richterlichen Erlass meine Daten rausrückt. Rob Gonggri und Twitter als Beispiel.

3. Obiges sind Missbrauch durch Dritte. Ich stimme dir zu, dass Google als Unternehmen selber wenig Interesse an Missbrauch hat. Nichtsdestotrotz existieren auch da Angriffsvektoren, so gibt es beispielsweise den dokumentierten Fall eines Ex-Google-Mitarbeiters, der bei Google gespeicherten Daten benutzt hat, um Teenager zu belästigen.

Dann können wir ja aufs eigentliche Problem zurückkommen, denn das halte ich für einiges interessanter und kniffliger.

Ich würde "das eigentliche Problem" nämlich wie folgt formulieren: Damit eine Datendienst wie Suchmaschine für den Benutzer optimal funktionieren kann, muss die möglichst viel über den Benutzer wissen. Google soll wissen, dass ich in Zürich lebe, damit ich das bei der Suchanfrage nach Handwerkern nicht angeben muss. Google soll meinen Kalender haben, damit ich ihn beim Freund am Laptop nachschlagen kann.

Dadurch entsteht ein Komfortgewinn. Es macht meiner Meinung nach kaum Sinn, Google möglichst wenig Daten zu geben (z.B. wie es niwax tut oder ich das früher getan habe). Das liegt nämlich nicht im Interesse des Nutzers - und in Zukunft wird diese Komforteinbusse nur noch grösser.

Die Kehrseite ist natürlich, dass dadurch ein Datenmonopol entsteht. Das will man einerseits rein wirtschaftlich nicht, andererseits macht das das Missbrauchspotential grösser: Einerseits könnte Google immer mehr Unsinn anstellen, andererseits werden Angriffe auf Google viel interessanter, weil man dann plötzlich über GMail Zugriff auf PayPal hat, oder man kann eine Person über die getätigten Suchabfragen erpressen.

Will man Datenschutz und Wettbewerb also nach wie vor gewährleisten, dann braucht es meiner Meinung nach technische Massnahmen. Wie wäre es z.B. wenn es einen Dienst gäbe, wo ich alle meine Daten in einen mehrstufig verschlüsselten Container packen kann, und Google und allen Diensten dann bei Bedarf darauf Zugriff gebe.

Die Frage ist, wie man so etwas einerseits sicher genug umsetzen könnte, andererseits auch bequem genug. Denn Vista-artige Sicherheitsabfragen ("Wollen Sie wirklich der Google-Suche ihr Adressbuch übermitteln?") schaden letztendlich mehr als sie nutzen.
Und die Frage ist, ob man einen solchen Standard gesetzlich erzwingen könnte - oder was sonst nötig wäre um so etwas zu erreichen.

Die Alternative dazu wäre ein gesellschaftlicher Wandel anzunehmen. Wenn sich die Einstellung zur Privatsphäre ändert und der Chef irgendwann kein Problem mehr mit Saufbildern hat, weils die eh von jedem gibt. Dann aber wiederum sehe ich rechtsstaatliche Probleme (Schutz der Minderheiten, Repressionen usw).

Zitat von klemmi

Meine Hausfassade lässt z.B. den Schluss zu, welcher Schicht ich angehöre: Villa oder Zimmer im Blockbau.

Google wird nicht deine Hausfassade mit aufwändiger Bilderkennung analysieren (von Hand schon gar nicht) um an diese Information zu kommen, sondern dein Such- und Kaufverhalten untersuchen, und ist damit noch viel exakter. Denn gibt genügend Leute deren Hausfassade nicht zu ihrem Milieu passt, da müsste man schon die Wohnung scannen.

Eine Hausfassade ist keine personenbezogene Information. Deine maschinenlesbare Adresse ist es, aber das maschinenlesbare Bild der Hausfassade alleine lässt keinerlei sinnvolle Rückschlüsse zu.

Erstens musst du bisschen differenzieren. Google weiss nicht wie dein Haus aussieht, weil mir kein Google Dienst bekannt wäre, der deine Adresse erfordert. Abgesehen von der Tatsache dass die Hausfassade eine herzlich uninteressante Information ist. Ähnliches gilt für den Realnamen. Ausser Google+ (und da herrscht kein Registrierzwang wie bei Facebook) kannst du bei jedem Dienst Pseudonyme verwenden. Ich will damit nicht sagen, dass es einem Data Miner nicht möglich wäre, diese Information zu extrapolieren. Aber gespeichert werden sie direkt nicht. Soviel zu den datenschutzrechtlichen Details.

Zweitens ist das Problem nicht Google. Google-Bashing mit "Datenkrake" wie man es anderswo liest, ist m.E. völlig unangebracht, denn gäbe es Google nicht, würde ein anderes Unternehmen den Zeitgeist ausnutzen und genau die gleichen Dienste anbieten. Die Nachfrage alle möglichen Daten maschinenlesbar gespeichert und abfragbar zu haben, ist vorhanden. Google macht lediglich das Angebot dazu.

Das heisst man kann jetzt zwei Dinge tun, um das Problem des Datenmonopol von Google zu diskutieren: Die Nachfrageseite (die Konsumenten) bearbeiten oder die Angebotsseite (die Unternehmen) zu bearbeiten.

Das Problem liesse sich angebotsseitig beispielsweise rechtlich lösen: Erstens etwas gegen das Quasi-Wirtschaftsmonopol von Google tun, zweitens stärkere Datenschutzrechte implementieren, die bspw. eine dezentrale verschlüsselte Speicherung der Daten verlangen. Aber auch das ist nicht so einfach, schlichtweg weil sich technisch wirksamer Datenschutz und benutzerorientierte Datendienste sich konzeptionell widersprechen.

Lange Rede, kurzer Sinn: Das Problem lässt sich nicht einfach lösen, vielleicht müssen wir uns damit einfach einrichten.

Der Beitrag ist schon viel zu lange, auf Wunsch formuliere ich gerne hier das eine oder andere noch aus.

Zitat von Pac-Man

Prio. A ist bei diesem Projekt nämlich, dass der Nutzer der DLL wirklich nur das sieht, um jetzt z.B. einen Sound abzuspielen, und nicht Hilfsmethoden etc., die intern verwendet werden.

Wird den Benutzer nicht davon abhalten, die Hilfsmethoden trotzdem zu verwenden, falls er das will.

Ich hab wie gesagt so gut wie keine Ahnung von MSVC, aber nach bisschen googeln sind mir noch folgende Dinge eingefallen:

1. Warum machst du nicht einfach für jede Klasse (z.B. Application) eine erbende Klasse ApplicationAPI, wo du alle public Methoden drin hast, während alle geheimen protected Methoden in der Vaterklasse Application drin sind - und ApplicationAPI wird dann in die DLL exportiert.

2. Wie entscheidet der Compiler überhaupt, welche Symbole in die DLL exportiert werden, und welche nicht? Es gibt ja offenbar eine Export-Anweisung, kannst du nicht einfach standradmässig alle Symbole versteckt halten und nur die exportieren, die du willst?

Zitat von niwax

Es ist aber sauberer, dem User die Funktionen zu geben, die er gebrauchen kann/soll als alles offenzulegen.

Dafür gibts API-Dokumentation.