You are not logged in.
Does installing the libmtp-runtime package fix things?
Credit to xaos52: https://crunchbang.org/forums/viewtopic.php?id=25200
And thanks to corenomial for keeping those boards running.
EDIT: **** me, I can still log in there and I'm still a moderator. Nice.
How about volumeicon-alsa? It works with PA & PipeWire as well, despite the name. No idea about Cinnamon though. That should have it's own volume control, I think.
Btw pure ALSA should work just fine unless you're video conferencing. I don't use any sound servers and everything works, even under systemd.
since Power ISA got open-sourced, there's an initiative to bring that back
Unfortunately POWER10 brought in a requirement for non-free firmware in the memory controller chips:
https://www.devever.net/~hl/omi
Not that it really matters because any POWER9 machine (or any of the "open" platforms you list) will need a hard drive and that drive will have a controller running proprietary code below ring 0. The battle is already lost.
the recent release of the Alibaba Roma RISC-V laptop
RISC-V is nice but the specification does allow for non-free extensions and I'm sure most, if not all, manufacturers will take advantage of that. To presume otherwise is naive.
My conclusion is, if we can work to keep our old (or simply pre-lockdown) hardware working long enough, say maybe another 10 years (depending on the device), we can wait this out long enough for those devices to become a bit more accessible to the common folk.
It seems to be getting worse rather than better but whatever.
There's a software package called Zeitgeist [...] It reads your emails, it monitors the websites you visit, listens to private conversations, and logs the files on your computer.. and then it shares this information freely over D-Bus to any application that wishes to use it. You are given no warning and have no option to say which software can access it, and which can't. Any software can access D-bus, including closed-source software like Discord or Telegram (whether they do or not, who knows)
So don't install it then.
The zeitgeist package is not installed by default in any of the desktop environments and it won't work properly in bare window manager desktops so this seems to be a complete non-issue.
Here is a list of the packages which will pull in zeitgeist:
$ aptitude search ~Dzeitgeist
p budgie-applications-menu-applet - Stylish Applications Menu for Budgie-Desktop
p cairo-dock-recent-events-plug-in - Recent events plug-in for Cairo-dock
p diodon - GTK+ Clipboard manager
p gir1.2-zeitgeist-2.0 - library to access Zeitgeist - GObject introspection data
p gnome-activity-journal - graphical user interface for Zeitgeist
p libdiodon0 - GTK+ Clipboard manager (main library)
p liblomiri-app-launch0 - library for sending requests to Lomiri App Launch
p libzeitgeist-2.0-dev - library to access Zeitgeist - development files
p libzeitgeist-cil-dev - CLI bindings for Zeitgeist Project - development files
p lomiri-app-launch - User space daemon for launching applications
p lomiri-app-launch-tools - Tools for working wtih launched applications
p python3-zeitgeist - event logging framework - Python 3 bindings
p synapse - semantic file launcher
p zeitgeist - event logging framework
p zeitgeist-core - event logging framework - engine
p zeitgeist-datahub - event logging framework - passive logging daemon
$
So unless any of those packages are installed zeitgeist will not be present.
Any tinfoil consumers can use this file at /etc/apt/preferences.d/stop-zeitgeist:
Package: zeitgeist*
Pin: version *
Pin-Priority: -1
^ That will stop any zeitgeist packages from ever being installed.
If the zeitgeist pakcage is installed then this file at ~/.config/autostart/zeitgeist-datahub.desktop will stop zeitgeist-datahub from starting in full desktop environments:
[Desktop Entry]
Name=Zeitgeist Datahub
Comment=Start the Zeitgeist Datahub for passive loggers
Exec=zeitgeist-datahub
Terminal=false
Type=Application
Hidden=true
The tracker service can be disabled and masked. Whether it gets surreptitiously enabled again is a question.
The zeitgeist services can be masked with
systemctl --user mask zeitgeist{,-fts}
Masking a service under systemd means it can never be started, even if called by DBus or another service. Debian packages will never run unmask, even for system services, and certainly not for user services, so that modification would be permanent.
The bad news is that sysvinit/runit/s6/OpenRC can't do masking, they have no concept of that very useful feature.
EDIT: spelling, removed misinformation.
The log looks normal. Anything in ~/.xsession-errors?
X does tend to bloat over time, or at least it did before I dropped it. Have you considered Wayland instead?
Very childish. If you don't care about the linux framebuffer, then I'm not sure why you're even involving yourself in a conversation about it.
Just trollin d00d.
It's old tech and it's fun to mess around with, and it's good to see that someone is doing the work to resuscitate and improve it
+1. Nice toy. Thanks for sharing.
how do you reconcile the differences between the totals of either ps_mem with free?
Shared memory usage in Linux is complicated, check the ps_mem code comments for details.
Looks like X is bloated for some reason. Can we see the log?
Any ideas to smooth this loading out?
Try this in ~/.xsessionrc instead of what I posted earlier:
# kill any existing pipewire instance to restore sound
pkill -u "$USER" -fx /usr/bin/pipewire-pulse 1>/dev/null 2>&1
pkill -u "$USER" -fx /usr/bin/wireplumber 1>/dev/null 2>&1
pkill -u "$USER" -fx /usr/bin/pipewire 1>/dev/null 2>&1
exec /usr/bin/pipewire &
# wait for pipewire to start before attempting to start related daemons
while [ "$(pgrep -f /usr/bin/pipewire)" = "" ] ; do
sleep 1
done
exec /usr/bin/wireplumber &
exec /usr/bin/pipewire-pulse &
Reference: https://git.alpinelinux.org/aports/tree/community/pipewire/pipewire-launcher.sh
To check memory usage try https://github.com/pixelb/ps_mem.
EDIT: also:
awk '/Rss/{Total+=$2} END {print Total/1024" MiB"}' /proc/*/smaps
Useless use of cat and useless use of grep. We don't need no stinkin' pipes...
You're welcome to test.
I've just ordered a TTL USB cable so I will do that as soon as it arrives.
EDIT: actually there's not much point because Debian's flash-kernel package doesn't support the RK3308 SoC. I plan to submit a WNPP bug report to try to add support. The board won't boot vanilla Debian until that is added. "$DEITY" knows I've tried...
EDIT2: and the u-boot-rockchip package as well. Busy busy and all before the freeze in a few weeks.
@aluma: does the phrase "apples & oranges" mean anything to you?
And at any rate I don't think kernel & initramfs hacking should be within Devuan's remit. Sounds like overstretch to me.
When BunsenLabs was starting up we did discuss creating a desktop task for openbox with the intention of upstreaming it to Debian but it never came to anything. I always thought it was a good idea but these days Plasma is very nearly as light as openbox/tint2 and is *much* prettier and more user friendly (IMO).
Also note that because no ARM machines with legacy boot were ever produced, installations will be UEFI-only
Just FYI: my ROCK Pi S aarch64 board does not support UEFI and I'm sure there are others that don't.
Might I ask where the source for the ISO image is? The GitHub repository tarball only contains the README.md file.
^ Thanks!
Let's Stay Together by Tina Turner, live in Rio, no less. What a talent.
Here are the requirements for Trinity - "Trinity desktop - 300MHz CPU / 256MB RAM / 3GB disk"
Dear me, what a bloat monster
One practical example of the usefulness of the raw framebuffer: My laptop has AMD graphics.. and I can use the open source amdgpu driver. That's great... except, in order for the kernel to load amdgpu, it requires closed-source non-free firmware and there's no way to know what that code is doing. Not so great.
So block the amdgpu module and use VESA in X instead then.
mplayer -vo fbdev2 file.mp4
I tried this with https://upload.wikimedia.org/wikipedia/commons/b/b4/Tearing-test.webm and the tearing in the console is absolutely atrocious, completely unbearable. Under Wayland (sway) that same video running in the same player is perfectly smooth with no tearing (or lag) whatsoever. This is with amdgpu and an AMD Cezanne iGPU. And the non-free firmware :-)
EDIT: and I couldn't get the console output to work without adding my user to the video group, which is completely unacceptable.
there's no requirement to actually use those functions though
Just as under the Wayland protocol then.
whose primary targets appear to be "high refresh rate" (aka gaming woo)
As a gamer I can happily confirm this. Linux is now a better platform for gaming than Windows, which pleases me much more than these shiny new toys irritate you.
With links and directfb, you can run a graphics capable web browser in a TTY as well... That means a browser capable of accessing the current-day internet for machines with <128MB RAM.
lol
Or just install an operating system that isn't ridiculously bloated by default:
^ oh look, it's OpenBSD running X with Dillo and memory to spare in a VM assigned 128MiB. Nice.
Or maybe, because needing to run a full-blown WM and compositor on something with no use for windowing or a GUI (e.g. a "digital picture frame" type device or monitor for a video stream) just to get basic framebuffer video output is patently silly?
So you haven't read the DirectFB specifications then?
Components running on DirectFB graphics backend are based on libdirectfb.so library. Compositing windowing system is performed by the default libdirectfb.so window manager module with libdirectfbwm_default.so plugin.
It's using both a compositor and a window manager...
As I said, Wayland is simpler, more direct and more widely adopted with better support.
I suppose evince should be marked as an suggested dependency on Atril and that would solve the issue, correct?
Are you still using Atril as the image viewer or did you change to Evince?
But in terms of this thread, is there anything more to do to resolve it?
If you are still using Atril as the image viewer and installing Evince fixed a bug in Atril then you should report that as a bug in the Atril package to the Debian maintainer using the reportbug package. See also https://www.debian.org/Bugs/Reporting.
I ended up using .xsession to start as HoaS suggested
For clarity: that should be ~/.xsessionrc.
Reference: https://wiki.debian.org/Xsession
Please open a new thread for backup solutions (or search the boards to read the extant threads on that subject). This thread is waaaaaaaay off topic now.
Well yes but Wayland offers similarly direct access to the video hardware via KVM.
Or to put in another way: why is running graphics from a console screen useful?
Very nice genxr :-)
My usual Arch desktop:
Firefox, Steam and two foot terminals running oksh locally and mksh over ssh to my music player.
I've just updated the upmpdcli package for Debian buster:
https://software.opensuse.org//download … e=upmpdcli
Upstream does have a buster repository but the current version won't build for buster because they've added a configuration GUI. My version strips out the GUI and Spotify support but does build for buster. Yay.
Running mpd & upmpdcli on the ROCK Pi S music player lets me stream Qobuz to it (and then to my DAC) from my smartphone using BubbleUPnP. Very civilised.
EDIT: 10 bonus points to anybody who can identify the book I'm reading in Firefox. No Googling!
Wayland compositors access the graphics hardware directly using KMS. What advantage does DirectFB2 offer over that? Seems like an unnecessary added layer for the current Linux graphics stack. Apologies if I am misunderstanding the protocol, I'm not an expert.
And why don't you try your own remedy before recommending it to me?
Because I couldn't be bothered. sorry to waste your time.
Try
menuentry "devuan5 preview" {
search.fs_uuid=$uuid
set isofile="/devuan_daedalus_5.0.preview_20221022_amd64_desktop-live.iso"
loopback loop ($root)$isofile
linux (loop)/live/vmlinuz boot=live fromiso=/dev/disk/by-uuid/$uuid$isofile username=devuan
initrd (loop)/live/initrd.img
}
Replace both $uuid instances with the actual (filesystem) UUID for /dev/sda9.
EDIT: btw hd1,9 in GRUB translates to /dev/sdb9. hd0,9 would be better but the UUID is the best approach IMO.