You are not logged in.
The Exec line in the .desktop file doesn't understand parameters, try this command instead:
sh -c "LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libv4l/v4l1compat.so /usr/bin/skypeforlinux"Both Devuan ASCII and MX-18 are based on Debian oldstable (stretch) but MX includes many backported packages.
Try comparing the configuration of the desktops, for example:
lspci -k | grep -iA2 'vga\|3d\|display'
xrandr --listproviders
glxinfo | grep 'OpenGL r'EDIT: the X.org log would probably be useful also.
user@intel60:~$ sudo apt install build-essential linux-headers-$(uname -r) [sudo] password for user: Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package linux-headers-4.9.0-6-amd64 E: Couldn't find any package by glob 'linux-headers-4.9.0-6-amd64' E: Couldn't find any package by regex 'linux-headers-4.9.0-6-amd64' user@intel60:~$
You're running an old kernel version so the matching headers are no longer available in the repositories.
First update your system then reboot into the new kernel version and install the headers:
# apt install module-assistant
# m-a prepareThen try the script again.
Must be firmware then.
# apt install firmware-misc-nonfreeYou may need to add the contrib & non-free components to your sources first though.
Thanks for the link, refracta2usb is indeed an awesome tool :-)
But I don't think it solves the problem I explained in my last post, nor does it unify the user authentication data in $HOME so that it can be ported to another machine. And systemd-homed will allow per-user resource constraints as part of the configuration.
He wants to take over your home directory...
If an encrypted laptop is suspended then the key has to be stored in memory, systemd-homed has been created to enable the user password and encryption key to be unified so that the key doesn't have to be kept where a malicious agent can extract it.
So it's a new feature that solves a genuine problem. What a bunch of bastards, eh?
I think elogind was originally created for GuixSD, adopted by Gentoo and then later packaged for Devuan.
Upstream: https://github.com/elogind/elogind
The version in Debian sid and Devuan beowulf & ceres is now fully ABI-compatible with libsystem0, albeit with most of the functionality stubbed-out.
If Debian should go systemd init only, will the Devuan development team be able to handle the added work of providing a systemd-free OS still based on Debian?
The elogind package which is the source of the linked problem was originally packaged up by Devuan and is also used by Gentoo so it should continue to work even if Debian drop it.
I don't see any trouble in that because it's not so hard to maintain existing sysv-rc scripts and make new ones.
It may not be "hard" but there are currently 1033 packages that ship systemd unit files without matching init scripts[1], they don't currently work properly under sysvinit.
And it looks like some Debian maintainers aren't even testing existing init scripts, let alone adding new ones:
Try
# apt install libavcodec-extraUnless you already have it in your Devuan system, ofc.
EDIT: does the stock firefox-esr package in Devuan work for you?
What does "Queriable via Varlink interface." mean?
I do like the resource control provided by systemd's interfaces for slices & control groups: certain users could be given specific CPU & disk usage limits, which is nice.
This seems to be part of the developers' greater drive towards stateless systems. The next step is the removal of all /etc-based configuration files:
When you need configuration files in /etc to work properly, consider changing your application to work nicely when these files are missing, and automatically fall back to either built-in defaults, or to static vendor-supplied configuration files shipped in /usr, so that administrators can override configuration in /etc but if they don't the default configuration counts.
So look out for the shift to /usr/share/apt/sources.list...
I'm afraid one day the systemd tentacle will extends on other systems like BSD, MAC or even Windows.
https://en.wikipedia.org/wiki/Systemd#systembsd
Not an official effort though: https://marc.info/?l=openbsd-misc&m=141135403820631&w=2
I believe they will try hard, I have heard that they are interested in BSD. LOL
At the moment the systemd package has a hard dependency on glibc and the corporate overlords are only really interested in maintaining the Linux dominance in the server & supercomputer markets. I don't think the Linux Foundation gives a crap about the desktop 'cos all the users are freeloading deadbeats. LOL.
Here's the latest infection from the parasite
Lennart actually describes it as home-on-a-stick in the video presentation, which amused me.
Portable, fully encrypted home directories with automated Yubikey authentication sound like a neat idea but it won't replace the traditional layout any more than systemd-networkd has replaced NetworkManager or Ceni.
Yes, you're right ![]()
Just create a file at ~/.config/chromium-flags.conf with this content:
--disable-field-trial-configAny other switches can be added (on their own lines) to the file as desired.
EDIT: actually that might be Arch-specific, I don't have Chromium installed here.
Easiest way is probably to copy the .desktop file to $HOME and modify the Exec statement to include the option:
mkdir -p ~/.local/share/applications
cp /usr/share/applications/chromium.desktop ~/.local/share/applications
sed 's/\/chromium/\/chromium --disable-field-trial-config/' -i ~/.local/share/applications/chromium.desktopAny menu entries should then run Chromium with the switch, use this to check for sure (once Chromium is running):
pgrep -a chromiumIf you're using gpt with legacy/bios boot, grub needs a special partition, at least 1MB size, unformatted and type ef02 in gdisk or bios_grub in gparted.
The OP has an NVMe drive which is almost certainly an advanced format (4k) type — such devices cannot be booted by GRUB in non-UEFI mode even if a BIOS boot partition is present.
From the article:
To still get a systemd-like session management, and thus retain the ability to shut down and restart the system as a normal user, I run the session manager "elogind" instead.
So they can do that because of the hard work of the Devuan developers ![]()
@pcalvert, why pin the rest of the repository to 50?
A pin value of 100 makes the MX repositories behave like backports, which sounds ideal for the intended purpose.
Also, their Flash package downloads updated Flash versions without needing to be updated itself so using the .deb might be the best option.
I was greeted with an error about not being able to use the guided install as the install disk isn't large enough - due to the system choosing the same size swap as amount of RAM in the server, naturally. And, naturally at least as far as I can tell, there is no way to change the size of that swap partition prior to the guided install attempt.
Preseeding the installer with the desired partition sizes might be an option: https://wiki.debian.org/DebianInstaller/Preseed
But I would just boot the installer with a mem=8g kernel command line parameter so that it only creates an 8GiB swap partition (mutatis mutandis).
How exactly did you install Blender 2.80? Did you just download the tarball, unpack it then run the blender executable?
If you start it from a terminal does it show any error messages when it freezes?
Yes, you're right. XFCE has a dependency on libpulse0 but that only recommends pulseaudio itself. The GNOME desktop has a hard PA dependency though, perhaps unsurprisingly. No need to remove it anyway: just stop it from starting if you don't want it, as noted by dxrobertson earlier in this thread.
My point was that all the standard desktop environments include PA even if it's as a recommended component rather than a dependency per se.
Thanks Geoff42, that's very helpful ![]()
The method I use is
E485:~$ cat /etc/modprobe.d/alsa.conf
options snd-hda-intel index=1
E485:~$It's also possible to use ~/.asoundrc to set the default card, antiX has a tool that will do this to switch cards in their PA-free desktop.
See also https://wiki.archlinux.org/index.php/Ad … ive_method
So yeah, ALSA by itself can be a tricky little devil. Which is why PA is so omnipresent.
Head_on_a_Stick wrote:The only people who don't use Pulseaudio these days are hair-shirt minimalists, all the desktop environments have PA as a dependency because it provides a convenient high-level interface for controlling how multiple sources are connected to sinks.
That's not true.
Which desktop environments do not have PA as a dependency?
Don't get me wrong, I'm sure you know better than all those silly DE developers but they do seem to like PA.
On every laptop i seen ALSA provided built-in speakers working by default. There is no need to configure ALSA.
From my laptop with my custom configuration for ALSA removed:
E485:~$ apt policy pulseaudio
pulseaudio:
Installed: (none)
Candidate: 12.2-4
Version table:
12.2-4 500
500 https://cdn-aws.deb.debian.org/debian buster/main amd64 Packages
E485:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Generic [HD-Audio Generic], device 7: HDMI 1 [HDMI 1]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Generic [HD-Audio Generic], device 8: HDMI 2 [HDMI 2]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Generic_1 [HD-Audio Generic], device 0: CX20753/4 Analog [CX20753/4 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
E485:~$ speaker-test
speaker-test 1.1.8
Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
ALSA lib pcm_dmix.c:1108:(snd_pcm_dmix_open) unable to open slave
Playback open error: -2,No such file or directory
E485:~1$ As you can see the HDMI output is the default and I have no sound from the internal speakers.
EDIT: speaker-test output added.
The following packages have unmet dependencies: libmount1 : Breaks: libmount1:i386 (!= 2.32.1-0.1+devuan2.1) but 2.33.1-0.1+devuan1 is to be installed libmount1:i386 : Breaks: libmount1 (!= 2.33.1-0.1+devuan1) but 2.32.1-0.1+devuan2.1 is installed libblkid1 : Breaks: libblkid1:i386 (!= 2.32.1-0.1+devuan2.1) but 2.33.1-0.1+devuan1 is to be installed libblkid1:i386 : Breaks: libblkid1 (!= 2.33.1-0.1+devuan1) but 2.32.1-0.1+devuan2.1 is installed libuuid1 : Breaks: libuuid1:i386 (!= 2.32.1-0.1+devuan2.1) but 2.33.1-0.1+devuan1 is to be installed libuuid1:i386 : Breaks: libuuid1 (!= 2.33.1-0.1+devuan1) but 2.32.1-0.1+devuan2.1 is installed libelogind0 : Breaks: libelogind0:i386 (!= 241.3-1) but 241.1-1 is to be installed libelogind0:i386 : Breaks: libelogind0 (!= 241.1-1) but 241.3-1 is installed
Looks like beowulf has different versions of those packages for i386 & amd64, this can also be seen in your apt policy output.
No idea why, the Debian buster repositories have the same versions for both i386 & amd64 (apart from xfsdump).