Beiträge von DosAmp

Egal ob man die Audiofunktionalität über ALSA (Altlösung, unterstützt nicht das neue HSP/HFP-Bluetooth-Profil) oder Pulseaudio herstellt, ist es trotzdem ggf. notwendig, über bluetoothctl das Neuscannen nach BT-Geräten anzustoßen, wenn man die Bluetooth-Lautsprecher nach der Ersteinrichtung und dem Start von bluetoothd angeschlossen hat.

Durch das Update für das Paket raspberrypi-bootloader wurden alle essentiellen Systemdateien auf /boot (Firmware, Linux-Kernel, Overlays...) erst durch Symlinks (fraglich wie diese überhaupt auf FAT32 funktionieren) ersetzt und anschließend gekillt.

Vermutlich reicht es, diese aus dem aktuellen Raspbian-Image zu extrahieren.

Zitat von Michael_

Ist folgendes korrekt?

Code

sudo mount /dev/sda5 /mnt
# …

Das dürfte schon mit deiner verschlüsselten Root-Partition nicht funktionieren.
Versuch mal folgendes:

# fragt nach Passwort
sudo cryptsetup luksOpen /dev/sda6 mein_root
sudo mount /dev/mapper/mein_root /mnt
sudo mount /dev/sda5 /mnt/boot
# ab hier vorerst Schritte wie oben
sudo mount proc /mnt/proc -t proc
sudo mount sysfs /mnt/sys -t sysfs
sudo mount /dev /mnt/dev -o bind
sudo mount devpts /mnt/dev/pts -t devpts
sudo chroot /mnt bash
update-grub
grub-install /dev/sda
exit
# Aushängen und Schließen des verschlüsselten Dateisystems
sudo umount -R /mnt
sudo cryptsetup luksClose mein_root
sudo reboot

Das ist merkwürdig, weil iw das Konfigurationstool für die nl80211- und wext die alte Wireless-Extensions-API ist. Aber über letztere läuft wpa_supplicant mit aktuellen WLAN-Treibern dennoch oft besser.

Jacob Tillberg – Ghosts

Das klingt plausibel und kann ich nachvollziehen.

Ein Adress-struct für ein Unix-Socket sieht so aus:

struct sockaddr_un {
    sa_family_t sun_family;
    char sun_path[108];
};

sa_family_t ist ein 16-Bit-Integer, also kommt das struct normalerweise bei 2+108=110 Byte heraus. Wenn man aber die von dir angegebene Option -mstructure-size-boundary=32 nutzt, bläst der Compiler das struct auf das nächste Vielfache von 32 Bit, also 112 Byte auf, und wenn man im bind-Systemaufruf dann wahrheitsgemäß 112 Byte als Größe der Adresse für ein Unix-Socket übergibt, verweigert der Kernel das mit EINVAL.

Zitat

EINVAL addrlen is wrong, or addr is not a valid address for this socket's domain.

Dieses minimale C-Programm wirft einen Fehler auf Linux/arm, wenn es mit -mstructure-size-boundary=32 kompiliert wird, aber ohne (bzw. wenn man statt sizeof(testaddr) den Wert 110 hartkodiert) funktioniert es.

#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>


#define SOCKET_PATH "/tmp/test.sock"


int main() {
        struct sockaddr_un testaddr;
        testaddr.sun_family = AF_UNIX;
        strcpy(testaddr.sun_path, SOCKET_PATH);
        int s = socket(AF_UNIX, SOCK_STREAM, 0);
        int bind_res = bind(s, (struct sockaddr *) &testaddr, sizeof(testaddr));
        if (bind_res) {
                perror("bind");
                return 1;
        }
        close(s);
        unlink(SOCKET_PATH);
        return 0;
}

Das scheint im Übrigen ein bekanntes Problem mit Netzwerk-Stacks auf ARM zu sein.
gcc auf x86 kennt -mstructure-size-boundary schon gar nicht erst.

Hast du Unix-Sockets im Kernel oder als Modul (CONFIG_UNIX)?

Für gewöhnliches X11-Forwarding über SSH sollte XMing 6.9 noch auf Windows 98 lauffähig sein (dann braucht man wirklich nur X-Client-Bibliotheken am Server), Cygwin/X könnte wegen der engen Kopplung an die POSIX-auf-NT-Bibliothek Cygwin selbst mit KernelEx haarig werden.

Ich glaube, direkt einen xvnc-Server zu betreiben ist jedoch in jedem Fall einfacher und portabler – gerade mit modernen Toolkits wie GTK+/Qt, die sowieso alles als Pixeldaten berechnen und bei denen das X-Protokoll größtenteils nur Overhead ist. Zudem ist auf Clientseite keine OpenGL-taugliche Hardware vorhanden.

Mit einigen Archivern auf Windows muss man Tarbälle erst dekomprimieren und dann entpacken.

Der Kanal hat auch ähnliche Cover anderer Videospiele.

Deichkind – Herz aus Hack

J.B.O. – Song, für den uns kein Name eingefallen ist

Generelle Software-Situation auf aktuellen (>= 5.0) Android-Geräten:
- Der eingebaute Mediendatei-Support umfasst das meiste, was man auf anderen aktuellen Geräten auch abspielen kann. Dazu gehören an Audioformaten MP3, Ogg Vorbis, AAC, (ab 4.0 wer unbedingt 100% CD-Qualität auf ein Mobilgerät quetschen will) FLAC und (ab 5.0) Ogg Opus und Videoformaten H.264 ("MP4-Video") als MP4/MKV.
Für Altformate aus dem letzten Jahrzehnt (z. B. WMA oder DivX-AVIs) gibt es genügend gute Mediaplayer-Apps, die dafür ihre eigenen Codecs mitbringen.
- Bluetooth 4.0 ist mittlerweile Standard, aptX für transparent komprimierte Musik wird von vielen Geräten unterstützt.
- Sideloading wird grundsätzlich immer unterstützt, was auch alternative App-Stores wie F-Droid möglich macht.

Von offizieller Seite hat WhatsApp für alternative Plattformen neben Blackberry, Symbian und S40 nie existiert.

Zitat

The format is comma separated list of "[ID:]VAL" where ID is PORT[.DEVICE]. PORT and DEVICE are decimal numbers matching port, link or device. Basically, it matches the ATA ID string printed on console by libata.

Also einfach nur libata.force=6.00:pio3 bzw. libata.force=6:pio3, wenn nichts anderes am primären IDE-Controller hängt.

Dein gewünschter Kernel-Bootparameter sieht so aus:

libata.force=PORT:pio3

wobei PORT für die Kombination aus IDE-Controller (1 oder 2) und Master/Slave (.00 oder .01) steht, so wie der Kernel das Gerät benennt (ataX.YY). Für SATA-Geräte (wenn man da z. B. NCQ oder Queued TRIM deaktivieren will) kann man natürlich letzteres weglassen.

Wenn man mit einem 32-Bit-Kernel bootet, wird auch nur eine 32-Bit-Architektur angezeigt. Vergleiche mit i686 auf einem 64-Bit-PC.

Genau wie bei XP würde ich mal neben dem letzten Agent das letzte Stammzertifikat-Update installieren.
Ich bezweifele jedoch, dass das die Sache erheblich beschleunigt; meine letzten Neuinstallationen habe ich erst mal mit Update-Packs von vertrauenswürdigen Seiten angestoßen.

… und läuft schon auf dem Server, ehe Mojang sich einen Blogeintrag aus den Rippen geleiert hatte.

Kann man sich erst mal zurücklehnen und die Fertigstellung einer neuen Overviewer- und Mod-Coder-Pack-Version abwarten.

Nein. Offenbar liegt es daran, wie package-query die API vom AUR aufruft. Im Moment funktioniert es mit der stabilen Version 1.7 nicht.

Jede Suchanfrage, die yaourt an das AUR stellt, wird durch einen Aufruf von package-query wie folgt gehandhabt:

package-query --aur-url https://aur.archlinux.org -s -A -- [Suchbegriff]

package-query ruft dann über cURL folgende URL ab:

https://aur.archlinux.org/rpc.php?type=search&arg=[Suchbegriff]

Das gibt aber neuerdings keine Ergebnisse mehr, da ohne Versions-Parameter v die veraltete Version 1 der API angenommen wird. Aktuell ist laut der Dokumentation Version 5.

Die Lösung ist, manuell die aktuelle Git-Version package-query-git aus dem AUR zu installieren, die dafür mehrere Bugfixes enthält.

Das sind die ersten vier deutschen Mirrors aus dem derzeit aktuellen Paket pacman-mirrorlist:

## Worldwide
#Server = http://mirror.rackspace.com/archlinux/$repo/os/$arch


## Germany
#Server = http://mirror.23media.de/archlinux/$repo/os/$arch
#Server = http://artfiles.org/archlinux.org/$repo/os/$arch
#Server = http://mirror5.bastelfreak.org/archlinux/$repo/os/$arch
#Server = https://mirror.compojoom.com/archlinux/$repo/os/$arch

Hier kann man sich im Übrigen seine eigene Liste mit Mirrors zusammenklicken, die bestimmten Faktoren (HTTPS, IPv6) genügen sollen:
https://www.archlinux.org/mirrorlist/