Archiv der Kategorie Apple

Safari Extension: HTML5-Video für Tagesschau.de

Die Tagesschau hat in den letzten Tagen ihre Video-Ausgabe-Formate etwas erweitert. Neben dem Format Ogg wurde auch etwas die Benutzerführung (in meinen Augen) verbessert.

Wie auch immer: Ich habe auf die Schnelle eine Extension geschrieben, welche die Flash-Player auf Tagesschau.de automatisch in entsprechende HTML5-Tags umwandelt. Der Code ist zur freien Verfügung unter GitHub einsehbar, der Download ist ebenfalls dort unter Downloads zu finden.

Beispiel anhand der Seite http://www.tagesschau.de/ausland/swift172.html

Tagesschau mit Flash

Tagesschau mit Flash

Tagesschau mit HTML5

Tagesschau mit HTML5

Der Code ist wenig-bis-gar-nicht dokumentiert, sollte aber bei der mehr oder weniger jQuery-Trivilität nicht notwendig sein. Eine Adaption für Chrome/Firefox sollte einfach sein. Wie man im Code sieht, habe ich sogar das Ogg-Format ausgelesen.

Resultat: HTML

Resultat: HTML

Anregungen sind gerne willkommen.

Derzeit werden nur die Filme auf normalen Artikeln ausgetauscht; keine Sidebars, mutmaßlich auch keine Extra- oder Spezialseiten. Außerdem ist – derzeit – die Kodierung auf H.264-High und Ogg fest eingestellt. Flash lädt im Vergleich immer H.264-Medium.

Android & “Open”

ars technica: Bloatware creeps into Android phones

Zusammengefasst lässt sich sagen: Die Provider haben bereits begonnen, “exklusive Zusatzleistungen” in Form von unlöschbaren Apps zu bringen. Und dabei handelt es sich nicht um Basics wie Mail oder Kalender, sondern PC-Bloatware-typischer Softwaremist halt.

Es scheint langsam so, als würde ein beachtlicher Teil von Androids “Open” von den Providern genutzt — und gleichzeitig zugemacht. Schade um den Grundgedanken an Android, aber es sind die Provider.. was soll man schon erwarten.

PS: Ja, das iOS hat auch einige Basics, die nicht zu löschen sind. Neben internen Apps wie den “Einstellungen” oder auch Essentials wie Mail und Browser sind dabei auch Wetter, Stocks, YouTube & Co. Streitbar, ob letzte nun wirklich jeder braucht.

Erste Safari Extension fertig: knallicious

Ich habe meine erste Safari Extension erstellt, als Versuchsballon in der ja noch sehr jungen Architektur. Die Extension knallicious ist, wie der Name wohl schon vermuten lässt, eine Schnittstelle zum Social Bookmarks Dienst del.icio.us. In der ersten Version beschränkt sich die Extension auf drei wesentliche Features:

  1. Per Buttonklick die aktuelle Seite bookmarken (taggen). Diese Funktion kann derzeit tatsächlich noch nicht mehr als auch die einfache “Lesezeichen mit Javascript”-Variante.
  2. Per Buttonklick zur eigenen Inbox springen. Zudem werden neue Inbox mit einem Badge-Counter im Button angezeigt.
  3. Ein Button zeigt an, ob die aktuelle Seite bereits gebookmarked wurde.

Eventuell werden noch weitere Plugins oder Updates veröffentlicht.

Safari Extension HTML5 Video Plugins

Nun würde ich nicht extra eine Safari-Extension für Golem.de hervorheben, wenn dabei nicht eine Sache wichtig wäre. Diese Extension ersetzt den Standard Flash Player mit einer HTML5-Variante.

Der nette Nebeneffekt (neben der Tatsache, kein Flash haben zu müssen):

  • das Video ist komplett werbefrei

Kein nerviger Visual Studio Werbekasten drumherum, keine “Werbe-Intro”. Nix.

Update: Hey, noch eins. Für Spiegel.de

MacOS X Security

Boah, was für ein Artikel. Geht zusammengefasst um das Sicherheitskonzept von MacOS X, teilweise im direkten Vergleich zu Windows. Unter anderem auch mit der These: Der geringe Marktanteil von Mac OS X ist nicht Schuld an kaum Malware.

Nicht überaus technisch überladen, also sehr verständlich (auf deutsch) erklärt.

Es sind zu viele Informationen auf einmal gewesen, aber beim ersten Durchlesen sind mir keine Fehler aufgefallen. Einzig allein den Passus, dass “Mac OS X” in großen Teilen offen läge, finde ich unglücklich formuliert. Der Autor meinte sicher, dass viele Komponenten (wie das in dem Kontext genannte Samba) offen sind und von Apple dort auch genutzt werden.

Fwd “Thoughts on Flash”

Der Herr Jobs hat sich öffentlich und ausführlich zum Thema Flash geäußert.

Mein persönliches Highlight ist

We have routinely asked Adobe to show us Flash performing well on a mobile device, any mobile device, for a few years now. We have never seen it. Adobe publicly said that Flash would ship on a smartphone in early 2009, then the second half of 2009, then the first half of 2010, and now they say the second half of 2010.

Und da behaupten manche noch immer, ein 3rd-Party-Provider wäre nicht so schlimm. Hallo, ein Jahr und mehr Verzögerung? Und es ist ja zu erwarten, dass die Performance erst mit weiteren Updates steigen wird.

If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

Das kommt doch meinem Beitrag schon nahe..

For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X.

Gut, verstehen viele Windowsnutzer nicht. Die arbeiten noch, oder bis vor kurzem, mit einem uralten Windows XP. Was sind da 10 Jahre..

Adobe vs. Apple

Es gibt derzeit eigentlich hauptsächlich zwei gute Artikel, wenn man sich mit etwas Hintergrundinformationen über diesen angeblichen “Krieg” (laut Presse…) bereichern will.

Zum einen hat John Gruber bereits vor einigen Tagen hübsch zusammengefasst, was es sich mit dem Multitasking und der Section 3.3.1 (das ist der Abschnitt, der Adobe zur Zeit die Galle hoch kommen lässt). Der Grundtenor: Es geht nur um die Kontrolle der Plattform (siehe unten). Außerdem können die fremden, 3rd-Party-Tools nicht alle Features wie Multitasking automatisch. Apple ist also darauf angewiesen, dass der Dritte dies mit einbaut. Der Anwender bekommt sonst ein inkonsistentes Produkt, und das will Apple nicht. Das ist eine Strategie, die sich bei der iPhoneOS-Produktpalette nachweislich bezahlt hat.

Desweiteren hat ein Entwickler auf seinem Blog /dev/why!?! sehr schön aufgezeigt, wer hier eigentlich wen angegriffen hat. Dem kann ich nur beipflichten, ich zitier die interessantestem Stellen, der Titel lautet: It’s all about the framework.

Imagine if 10% of the apps on iPhone came from Flash. If that was the case, then ensuring Flash didn’t break release to release would be a big deal, much bigger than any other compatibility issues.

[…]

Shipping a release where they break a large percentage of apps is not generally an option. Letting any of these secondary runtimes develop a significant base of applications in the store risks putting Apple in a position where the company that controls that runtime can cause delays in Apple’s release schedule, or worse, demand specific engineering decisions from Apple, under the threat of withholding the information necessary to keep their runtime working.

[...]

So ultimately, preventing Flash on the platform is about control, but is not control over the user experience of the Flash applications, or even the languages used. It is about the runtimes they bring on to the system, and Apple’s control over future releases of iPhone OS.

Diese Problematik ist den meisten Trollen unserer hiesigen IT-Welt natürlich völlig fremd *g* Man muss sich das auf der Zunge zergehen lassen: Als Unternehmen einen potenziell nicht kleinen Teil der Anwendungen aus der Hand zu geben, mit allen Konsequenzen. Und das Haupteinfallstor Nummer 1 auf PCs (und auch Macs) ist… jawohl, Flash. Die Betriebssysteme (auch Windows) sind heutzutage meist sehr gut abgeriegelt, aber Flashlücken tauchen dauernd auf. Microsoft ist machtlos, Apple ist machtlos. Und den Pinguinen ist das total latte.. :)

There is no doubt in my mind that if they asked Apple to bless this they were rebuffed, and if they didn’t ask the only reason they didn’t was because they knew Apple would say no. In either event, they announced the product to their customers and sold them on an idea they were not in a position to deliver, hoping Apple would be unwilling to piss off developers by not fulfilling Adobe’s promises. They tried to force Apple’s hand by putting Apple in a position where in order stop the Flash they would have to do it publicly in front of Adobe’s users. That was a bad call on Adobe’s part.

Das ist eine völlig neue Perspektive: Das Ganze wäre nur ein taktisches Spielchen seitens Adobe, in welchem es nur zwei Auswege gab. Spiel ohne Trumpf, und mit hohem Einsatz. Und ganz wertfrei betrachtet: Es ist gut, wenn man nicht sofort vor anderen großen Firmen kuscht.

They can get an awesome, high performance, Flash environment working on Android, and get a bunch of great Flash apps running on Android phones. As much as Apple wants to control iPhone, I am willing to bet they want to beat Android more.

Tja, und da haben wir das Problem: Ich glaube nicht, dass Adobe das in der nächsten Zukunft machen werden. Die hatten genug Power und Geld, das in den letzten 3 Jahren zu machen; da bestand aber wohl keine (wirtschaftliche) Interesse. Warum sollten sie also jetzt damit anfangen?

Every day Adobe does not have a widely deployed mobile Flash, is a day they are not having Flash based mobile apps developed, and is a day the odds of mobile Flash being successful goes down a little bit.

[…]

That’s right, Adobe has been making the case for Flash on iPhone for 3 years, but still hasn’t deployed a non-lite version of Flash on any phones, even when Apple is not obstructing them.

Zusammengefasst lässt sich sagen: Für den Anwender kann das ganze nur positiv ausgehen — und deswegen ist es auch gut so:

  • Adobe schafft es tatsächlich und bringt mobil-optimierte Versionen der Flashruntime heraus, die zudem auch mit speziellen Geräteeigenschaften ausgestattet sind. Sie müssen zeigen, dass sie auch Neuerungen zeitnah (oder gleichzeitig) herausbringen. Stellt sich hingegen heraus, dass ein Flashplayer auf Android auch erst Monate später die neuen Features unterstützt, dann…
  • Adobe bringt wirklich mal einen optimierten Flashplayer für Mac OS X heraus (derzeit gibt es wohl eine WebKit nightly + 10.1-Beta, die ja scheinbar wirklich Welten besser ist).. wäre ja nach jahrelanger Stromverschwendung der CPU auch mal Zeit, oder?
  • Adobe schafft es nicht, und die Anwender können sich nicht über unzureichende Akkulaufzeiten oder Userinterfaces bei der Plattform “iPhone OS” beschweren. Denn was ein Entwickler zu unterscheiden weiß, das kann der Anwender nicht (“Ist das ein Flashspiel?”).

Apple, Flash – ich bin nicht alleine

Auch andere haben sich mit diesem Thema in den letzten Tagen befasst.

Zum einen gibt es einen Artikel auf TUAW, zum anderen auch einen umfangreichen Blogbeitrag. Gerade letzterer verfolgt ähnlich meinem Beitrag nicht nur die iPad/Flash-Thematik, sondern auch die allgemeine Performance in iPhoneOS als auch Mac OS X. Die herausragendsten Passagen sind sicherlich folgende.

Serlet didn’t name any specific guilty plugins. Just “plugins”. But during the week at WWDC, I confirmed with several sources at Apple who are familiar with the aggregate Crash Reporter data, and they confirmed that “plugins” was a euphemism for “Flash”.

In other words, in Apple’s giant pile of aggregate crash reports — from all app crashes on all Macs from all users who click the button to send these reports to Apple — Flash accounts for more of them than anything else.

Jo. Warum kommt das jetzt jedem so bekannt vor.. :( Ein weiterer Grund: Apple musste auf Adobe warten, bis die sich endlich mal dazu bequemen, eine 64-Bit-Version herauszubringen. Da das ja bekanntlich nicht der Fall ist, Mac OS X aber 64-Bit laufen soll.. musste eine entsprechende Abstraktionsschicht für Browserplugins (also ein eigener Flashprozess..) her. Die Alternativen wären gewesen: Kein 64-Bit-Safari oder gar kein Flash.

It’s a chicken-and-egg problem. Publishers use Flash for web video because Flash is installed on such a high percentage of clients; clients support Flash because so many publishers use Flash for web video. Apple, with the iPhone, is solving the chicken and egg problem. For the first time ever, there is a large and growing audience of demographically desirable users who don’t have Flash installed. If you want to show video to iPhone users, you need to use H.264.

Machtpositionen sind manchmal zu was nützlich.

Und zuletzt spricht er über die Performanceproblematik von Flash/Mac OS X*. Ingesamt doch ein bisschen interessant zu lesen.

* Da geht es um die Sache mit der fehlenden H.264-Unterstützung in Form einer Public API, Flash auf die Mac Hardware zugreifen kann. Während das natürlich unschön ist, erklärt das aber immer noch nicht die beschissenen Laufzeitverhalten. Wenn eine Flash-Anwendung keine (H.264)-Videos und hochauflösenden Bilder hat, warum sind die Performancestats so beschissen?

Apple und die Sache mit Flash [Update]

Nun wissen wir endlich alle, wie der neuste Wurf von Apple heißt: nicht iTablet, kein iSlate sondern iPad. Okay, eigentlich hätte man auch iPod Touch Pro nennen können, den mehr ist es – erstmal – auch nicht. Klar, ein größeres Display und die daraus resultierenden weiteren Möglichkeiten, die die Apps/UI damit bieten, sind es dann schon.

Weiterhin scheint sich Apple aber zu sträuben endlich auch Flash auf ihre mobile devices zu bringen. Während es bei der iPod Touch/iPhone-Palette durchaus verständliche Gründe aus Sicht der Performance und auch der Usability gibt, werden diese Gründe bei iPad natürlich geringer. Warum also sonst?

Performance

Leider haben Flashobjekte immer wieder die Angewohnheit, sowohl CPU- als auch RAM-lastig zu sein. Ob das nun ein Problem vom Flashplugin oder vom zuständigen Entwickler ist, das kann man so natürlich nicht sagen. Dazu kommt, dass Adobe sich nicht imstande sieht, für Nicht-Windows-Systeme eine ordentliche Version es Flashplayers herauszubringen.

Oder um es mal am Beispiel zu nehmen: Es ist definitiv nicht normal, dass ein Flashspiel wie Farmville auf einem iMac Core 2 Duo mit knapp 3Ghz und 4 GB Ram gerne mal 50-150% CPU und das Flash-Plugin alleine (also ohne Browser) über 200 MB beansprucht. Und zwar im “ohne Details”-Modus. Youtube-Videos sind da mit 40% und nicht nennenswertem RAM-Verbrauch gelinde gesagt überschaubar.

Diese Probleme könnten auch auf dem iPad oder iPhone auftreten, ein Umstand, den Apple definitiv vermeiden will. Performance-Killer sind nicht erwünscht (irgendwie auch verständlich).

User Interface (UI)

Flashanwendungen sind immer für eine Interaktion mit einer Maus konzipiert. Wie sollen die mit einem Touchpad harmonisieren? De facto bedeutet das, das eine Reihe von Flashanwendungen nicht “funktionieren”, weil das Plugin keinen richtigen Unterschied zwischen Bewegen und Klicken oder Rechtsklick vermitteln kann bzw. das “Mauszeigerziehen” überhaupt nicht in der Form vorhanden ist. Und iPhone/iPad spezielle Gesten sind komplett unbekannt. Eine große Inkonsistenz – und von Adobe habe ich in der Richtung noch nichts gehört. Das ist auch nicht im Sinne von Apple, die ein konsistentes System anbieten wollen.

Stichwort Konsistenz: Selbst die einzelnen Flashplayer haben alle eine eigene UI und Benutzerführungslogik: Zusammenfassend kann man wohl sagen, dass der Play-Button meistens links ist. Mal darf man zoomen, mal gibt es Vollbild, mal darf man spulen. Manchmal ist der Button rund, mal ist er eckig. Das passt ebenfalls nicht in die konsistente und einfache Welt des iPhones – und iPads.

Nicht zu vergessen sind natürlich noch diese “Hammer-Player-mit-jedem-Schnickschnack-der-möglich-ist”-Flashanwendungen, bei denen definitiv ein Koller vorprogrammiert ist.

Die Alternative, einfach die Funktionen zu reduzieren, ist natürlich eine Sache von Adobe und vom dem Entwickler. Und, nein, nicht wirklich eine Option (die genutzt würde).

Festzuhalten ist also: native App > Web App > Flash App

Flash für alles und nichts

Flash ist eins der meist verbreitesten Internetplugins, und tatsächlich haben viele Seiten ein Flash “versteckt”.

  • Werbung (und danach kräht außer der Werbebranche nun wirklich keiner nach);
  • komplexe Anwendungen (wie etwa auch o.g. Farmville), die wohl als native bzw. Device-optimierte App wesentlich besser geeignet wären;
  • Flashvideoplayer;
  • “Ich-wusste-es-nicht-besser”-Statements.

Letzteres sind Dinge wie Navigationsmenüs oder “Webseitenlogos” in Flash, die in der Regel ein gutes Statement zur Inkompetenz aufweisen. Der Großteil ließe sich mit HTML/CSS/Javascript auch lösen (und ja, das Web bietet auch kostenlose(!) Frameworks für Animationen) – und das zu einem Bruchteil der benutzten Browserperformance. Aber Unkenntnis und das Flash-Buzzword bieten halt leider viel Potenzial für solche Lösungen. Nur einige hoch angesetzten (oder utopisch?) Anforderungen müssten wirklich Flash nutzen; und natürlich nur aus Flash bestehende Anwendungen. Diese Webseitenbetreiber wissen aber auch, dass sie damit eine Reihe von Leuten ausschließen (und sei es nur mangels großem Display). Kann sich jemand wirklich und ernsthaft die ZDF-Mediathek als Flashanwendung vorstellen? Auf dem iPhone? Auf dem iPad? Letzteres vielleicht, aber auch nur wenn die Auflösung mitspielt, denn Flash hat stets eine fixe Größe. Eine native App würde wohl jeder vorziehen, wohl auch zu Recht..

Am Beispiel: Die gesamte Produktpalette von Google wäre sicherlich nicht so erfolgreich, wenn sie Lösungen aus Flash nutzen würde. Man stelle sich das vor, Google Mail oder auch Microsofts Outlook Web als eine große Flashanwendung. Unfassbar, jeder würde den Kopf schütteln.

Als Fazit: Alternativen – und was wohl dahintersteckt

Als eine die Alternative für Flash ist HTML5/CSS3 anzusehen, welches u.a. eine starke Unterstützung für “Anwendungen” im klassischen Sinne anbietet.; beispielsweise Datenbank-API, File-API und natürlich das Video-Tag. Apple ist auf den Zug aufgesprungen, als sie das iPhone (in der ersten Version, wohlgemerkt!) mit dem hauseigenen Browser WebKit ausstatteten. Unterstützt mit der Tatsache, dass sie ein paar Ergänzungen in ihrer MobileSafari im Vergleich zum normalen WebKit machen, besitzen iPod/iPhone/iPad damit einen leistungsstarken Browser. Nicht ohne Grund setzt auch Google in Adroid auf diese Browserengine, wenngleich mit anderer Javascriptengine.

Der Browser selber hat im Gegensatz zu Flashplugins (die quasi ja nur eine Schnittstelle zu einer anderen Anwendung herstellen) den großen Vorteil, dass sein UI durch das Betriebssystem gesteuert wird. Im Gegensatz zum Flash, wo dies jeder Entwickler selber macht.

Flashvideo? Brauchen wir nicht, der HTML5-Videotag macht’s möglich. UI-Effekte wie Transformationen (größer, kleiner, verschieben, Farbwechsel) mit Javascript oder sogar Flash? Brauchen wir nicht, geht mit CSS3. Eine Flashapp zum Speichern von Daten (serverseitig)? Braucht man nicht, geht auch mit HTML5/Javascript. Außerdem gibt es integrierte Offline/Online-Sync-Möglichkeiten.

Für mich sind mögliche Offline-Webanwendungen ein Killerfeature für mobile devices, denn warum soll “Netz nicht verfügbar” immer bedeuten, das ich jetzt machtlos bin?

Um wieder zum Anfang anzuknopfen: Man hatte natürlich gehofft, das Apple ein Flashplugin für das iPad anbietet bzw. es unterstützt. So wie es im Moment aber aussieht, ziehen sie – mehr oder weniger direkt – gegen Adobe in den Krieg und setzen dabei weiterhin komplett auf HTML5 bzw. auf native Apps. Da die Geräte – glücklicherweise – eine gewisse Machtposition im Sektor der online mobile devices besitzen, sind die Anbieter von Diensten auf Alternativlösungen angewiesen, falls sie die doch große (und vor allem: sehr wichtige) Zielgruppe nicht ausgrenzen wollen. Davon können im Ende alle profitieren, wenn die *** proprietäre Flashgeschichte schwindet und stattdessen kleine, Client-performante und offenere Lösungen entstehen.

Übrigens: Auch Google setzt bekanntlich auf HTML5. Nicht nur Google Gears wurde entwicklungsplanmäßig in die Tonne gehauen, sondern auch Neuentwicklungen entstehen alle im Fokus der HTML(5)-Features. Das neue Google Voice (leider ein unschöner US-only-Kandidat) bietet VoIP. Kein Flash, pures HTML/CSS/Javascript.

Und mal ehrlich: Vermisst jemand wirklich das Flashplugin auf dem iPhone? Oder: Nutzt jemand wirklich Flash auf einem anderen Smartphone so intensiv, das es notwendig ist? Wenn ja, für was?

Update, 29. Januar 2010

Tatsächlich gibt es Ansätze, wie man Multitouch und Gesten in Flash umsetzen kann. Denn eine Maus und einen Mauszeiger findet man auf Multitouchgeräten nicht – um Gegenteil: man hat mehrere Pointer. Das bedeutet aber nicht, das vorhandene Flashanwendungen das alle nutzen würde, haha. Zu früh gefreut.

Howto: trac auf Mac OS X 10.6

Für den privaten Gebrauch – und für unterwegs, auf dem mobilen – kann sowohl ein Subversion als auch trac sicherlich eine Offline-Alternative sein.

Tatsächlich suchte ich nun eine Möglichkeit, “mal eben” eine trac-Instanz aufzusetzen: Auf dem Webserver erschien mir zu komplex und kompliziert, eine neue VM auf dem Macbook etwas ineffizient, oder? :) Also warum nicht direkt unter OS X, bzw. technisch gesehen BSD?

Die initiale Suche nach der Thematik bringt einen schnell zu einer Fink-Lösung – also mal ehrlich, schon etwas aufwendig?

Tatsächlich gibt es auch einfachere Varianten, etwa hier. Aber auch hier wird noch einiges runtergeladen, kompiliert.. ach, Informatiker sind von Grund her faul. Nein, das ist es auch nicht.

# python2.6 ist bereits installiert.
python -version
> Python 2.6.1

Die abgespeckte, und funktionstüchtige Methode lautet daher – kurz und knapp:

sudo easy_install Pygments
sudo easy_install Genshi
sudo easy_install Trac

Das war es, trac ist installiert.

Für diejenigen, die nun auch eine Schnelleinweisung in eine erste Konfiguration brauchen, ein Schnelldurchlauf. Bemerk: Natürlich können auch andere Pfade für die Repositories verwendet werden, wichtig ist nur: Der eigene Benutzer muss später Lese- und Schreibrechte besitzen. Das heißt im Klartext: Entweder nachher “umgranten” mit chown, oder woanders hinpacken. Auf /usr/local hat in der Regel nur der Superuser Zugriff, d.h. hier muss mit sudo gearbeitet werden.

# ein neues Subversion Repository anlegen
svnadmin create /usr/local/svn
# ein neues trac Repository anlegen - man kann alle Standardwerte nutzen, evtl. Pfad ändern
trac-admin /usr/local/trac initenv

Trac liefert einen kleinen Miniserver mit, der für diesen Zweck erst einmal reicht.

tracd --port 8000 /usr/local/trac/

Voilá.

Selbstverständlich brauchen wir noch einen User, zum Einloggen. Beispiel für den Benutzer user.

htpasswd -c /usr/local/trac/trac.htpasswd admin
> New password:
> New password:
> Re-type new password:
> Adding password for user admin
htpasswd /usr/local/trac/trac.htpasswd knalli
> New password:
> New password:
> Re-type new password:
> Adding password for user knalli

Jetzt den Server mit erweiterteten Parametern starten, also beispielsweise:

tracd --port 8000 --basic-auth=trac,/usr/local/trac/trac.htpasswd,trac /usr/local/trac

Eine Konfiguration über Apache2 ist dauerhaft eventuell zu empfehlen, aber für’s erste reicht es auch so. Ebenfalls empfiehlt die Dokumenation den Einsatz des Parameters –auth (Digest), dazu bitte jene konsultieren.

Page optimized by WP Minify WordPress Plugin