I had this problem for month with couple of workstations.
Either the client didn't install, or after installation there weren't any advertisements in the "RAP" (Run Advertised Programs)
Um mal ein wenig Ordnung in das ganze Chaos zu bringen, arbeite ich gerade an einer Trennung der FUN und Technik-Einträgen voneinander. Mir geistert da so ein konkreter Plan in meinem Kopf herum und da macht er auch irgendwie Sinn...
***UPDATE***
Scheint nach ein wenig Heck-Meck funktioniert zu haben
Allgemeine Infos bleiben im hier.
Listige Sachen werden im Fun-Blog gesammelt.
Technische Sachen werden hier im Blog veröffentlicht und wandern zeitgleich ins wiki welches ich noch aufbaue.
-OPTIONS="-w"
STATEDIR=/var/run/rpcbind
if [ -f /etc/default/rpcbind ]
then
@@ -34,6 +33,12 @@ start ()
{
if [ ! -d $STATEDIR ] ; then
mkdir $STATEDIR
+ else
+ if [ -e $STATEDIR/portmap.xdr ] || \
+ [ -e $STATEDIR/rpcbind.xdr ]
+ then
+ set -- -w ${1+"$@"}
+ fi
fi
if [ ! -O $STATEDIR ] ; then
log_begin_msg "$STATEDIR not owned by root"
===================================================================
Just found a link to Linus Torvalds explaination about C and C++.
BEST! EVER!
From: Linus Torvalds linux-foundation.org>
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-06 17:50:28 GMT (4 years, 8 weeks, 1 day, 17 hours and 45 minutes ago)
On Wed, 5 Sep 2007, Dmitry Kakurin wrote:
>
> When I first looked at Git source code two things struck me as odd:
> 1. Pure C as opposed to C++. No idea why. Please don't talk about portability,
> it's BS.
YOU are full of bullshit.
C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do nothing but keep the C++ programmers out,
that in itself would be a huge reason to use C.
In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said "to piss you off", but it's actually true. I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really would prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.
C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:
- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)
- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.
In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.
So I'm sorry, but for something like git, where efficiency was a primary
objective, the "advantages" of C++ is just a huge mistake. The fact that
we also piss off people who cannot see that is just a big additional
advantage.
If you want a VCS that is written in C++, go play with Monotone. Really.
They use a "real database". They use "nice object-oriented libraries".
They use "nice C++ abstractions". And quite frankly, as a result of all
these design decisions that sound so appealing to some CS people, the end
result is a horrible and unmaintainable mess.
Als ich eben einen silbernen smart am Büro-Fenster vorbeifahren sah, dachte ich, dass der ja von Mercedes ist. Was wäre, wenn Apple sich auf neuen Gebieten austoben und auch ein Auto auf den Markt bringen würde? Hätte das Erfolg?
Ich denke, es wäre ein Verkaufs-Knaller. Und das, obwohl die Apple-Fanboys und -Fangirls einige Einschränkungen in Kauf nehmen müssten, die sie auch jetzt schon bei iPhone, iPad und so weiter ohne Murren hinnehmen…
1. Steve Jobs wird es als “Revolution auf dem Automarkt” bezeichnen und BILD überschlägt sich mit Headlines wie “Welches iAuto ist ideal für mich?”
2. Sprit gibt’s nur im AppStore. Man muss mit etwa 2,99 EUR pro Liter rechnen. Man kann ihn direkt nach der Kaufabwicklung runterladen und installieren.
3. Zum Ölwechsel und für Reparaturen muss man das iAuto einschicken. Das nötige Versandmaterial bekommt man für 39,95 EUR bei Apple Deutschland.
4. Support gibt es über eine kostenlose Hotline. Allerdings muss man den Support bezahlen, wenn man den Fehler selbst verursacht hat (also immer).
5. Schalten, Gasgeben und Bremsen geht nur per Touchscreen. Aber der kann Multitouch und das hat sonst kein anderes Auto.
6. Der ADAC kann vor Ort keine Diagnosen vornehmen, da es keinen Anschluss für Testgeräte gibt. Siehe Punkt 3.
7. Das iAuto wird etwa drei Generationen und 4 Betriebssystem-Versionen brauchen, bis es endlich das kann, was sich die meisten Kunden wünschen.
8. Eine Bedienungsanleitung gibt es nicht. Man bekommt nur ein Blatt mit Hinweisen mitgeliefert, wie man das iAuto in Betrieb nimmt. Der Rest steht ja im Internet.
9. Die erste Aktion ist: Mit iTunes verbinden, 12 GB Updates runterladen und installieren. Ansonsten fällt es in den Sicherheitsmodus zurück und springt nicht an.
10. Nach 2 Jahren gibt es auch ein iAuto shuffle. Es hat keine Fenster und entscheidet per Zufallsgenerator, wohin man fährt. Aber auch nur dann, wenn man HSDPA-Empfang hat – ansonsten bleibt’s stehen – zur Sicherheit.
Wie gesagt: Die Apple-Lover würden es trotzdem kaufen … es ist immerhin von Apple!
Vor Kurzem hatte ich nach einem Update Probleme mit Kaffeine und der oberen Fehlermeldung. Heute habe ich mir die Zeit genommen ut etwas gegoogled.
Im Debianforum fand ich einen rel. frischen Eintrag mit exakt meinem Fehlerbild. Das Beste dabei: idanse postete die Lösung, die auch mir weiterhalf:
Gelöst habe ich es durch eine Änderung in der Datei xine-config in
/.kde/share/apps/kaffeine/ im Abschnitt "audio driver":
# audio driver
# { auto pulseaudio sndio alsa oss jack none file }, default: 0
# audio.driver:auto
Die letzte Zeile habe ich wie folgt geändert:
# audio driver
# { auto pulseaudio sndio alsa oss jack none file }, default: 0
audio.driver:alsa
Also auskommentieren (# entfernen) und "alsa" als audio.driver eintragen.
Danach lief kaffeine wieder. Mit "oss" ging es übrigens auch. Mit "pulseaudio" läuft es nicht.
Bei Xine selbst ließ sich das Problem auch dadurch beheben, dass als Audiotreiber "alsa" oder "oss" gewählt wurde (statt auto oder pulsaudio).