![]() |
Quote:
Code:
PY3=python$(python3 -c 'import sys; print("{}.{}".format(sys.version_info.major, sys.version_info.minor))') Code:
CFLAGS="$SLKCFLAGS -I/usr/include/python$PY3 |
The Slackware -current have a fine Wayland support and my favorite way to run Plasma5 is on Wayland sessions.
Particularly, the Wayland/Plasma5 looks acting more fluid, with absolutelly no tearing and somehow it feels faster on my MinisForum Z83-F mini-PC driven by an Atom Z8350 with 4 cores and 4GB RAM. BUT, I noticed that on Slackware is a single Wayland desktop solution right now: this Wayland/Plasma5. I think that there is a lack of a lighter desktop alternative/solution for Wayland, let's say... the equivalent of what is FluxBox or FVWM for X11. So, there's my proposal for -current for addition of reference (and minimalist) compositor of Wayland: Weston. It's repository is there: https://gitlab.freedesktop.org/wayland/weston/ It looks like this: https://gitlab.freedesktop.org/wayla...screenshot.jpg And we have already a SlackBuild for it: https://slackbuilds.org/repository/14.2/desktop/weston/ |
Register with the Linux counter project
|
|
Quote:
Code:
Sun Feb 21 20:02:02 UTC 2021 |
Quote:
If some such things are to be launched, a better place is at the beginning of rc.inet2. I fact, it'd be much better to also move the call to rc.firewall to the beginning. |
Quote:
|
Please consider applying the KWin patch shown bellow for permitting running Wayland/Plasma5 sessions as root:
https://invent.kde.org/plasma/kwin/-/merge_requests/679 https://invent.kde.org/plasma/kwin/-...ests/679/diffs Code:
diff --git a/main_wayland.cpp b/main_wayland.cpp I think that the KDE developers opinions about root account aren't news to anyone, as they in the past blocked various programs to run as root for "user own protection" , for example Kate or Dolphin. With Wayland/Plasma5 they blocked the entire desktop session, by refusal of kwin_wayland to run as root. However, I believe that considering the nazi security of Wayland, even running as root a Wayland/Plasma5 session, it will be way more secure than its X11/Plasma5 counterpart. In other hand, we already remove those root blockings for Dolphin and Kate, and unblocking also Kwin_wayland, will permit to have on Wayland/Plasma5 a alternative on pair with X11/Plasma5. |
LuckyCyborg: what can you do starting the whole graphical environment as root that you couldn't do otherwise? Why not run applications individually as root when needed instead? This a genuine question, use cases or practical examples welcome. X can be started as root indeed, but I never felt a need to do that, hence the question.
PS I am a bit surprised that the lock be at the windows manager level. What if user replaces Kwin by another one in a session or permanently. Isn't it possible with Plasma 5? PPS. I just tried: in Mate "kwin --replace" works as "compiz --replace". In KDE4 marco --replace works as well as compiz --replace (to some extent as the windows manager is not supposed to be the last component started when opening a desktop session). |
Quote:
Not exclusive to what you are suggesting, I'd like to see the instructions go the other way and fully adopt xorriso's native syntax without relying on the mkisofs emulation. But that's homework for me as well, which I've not completed. For the moment I'm relying on the -graft-points feature (or the emulation thereof) to get what I want. xorriso has -cd and -cdx and -cpr and such to manipulate the filesystem image under construction, which provides additional flexibility that may come in handy. Though for now, -graft-points is sufficient. |
I'd personally hope not to see root login patches in the main distribution: In the majority of cases it's good to discourage/disallow full root GUI use (e.g., it's actually helpful to new users), for the cases where it's wanted (maybe some kind of GUI rescue/repair kit?), special customization can be done for the purpose. :twocents:
|
Quote:
OK, there was that openSUSE patch which added support for XAuthority on Wayland, BUT it was not used by Slackware, even I proposed it. My intention is to bring the Wayland/Plasma5 on pair with X11/Plasma5 so the ability of running as root is a feature which is needed for a fine user experience. Quote:
However, this is not a KDE invention, as Wayland/Gnome3 has Mutter as Wayland server/composer and even Weston has, well... the Weston. Essentially, the Wayland itself contains just a library to write Wayland servers, so every desktop environment writes one as they likes and with features as they likes. For example Wayland/Gnome3 has a session management on pair with X11/Gnome3 while Wayland/Plasma5 is capable right now to restore only the applications running on X11 mode via XWayland. BTW, there's the first RC of standalone XWayland 21.1.0 : https://lists.freedesktop.org/archiv...ry/060615.html Did you understand what they intend to do - not that they keep it secret? The single maintained part from the Xorg sever will be soon the XWayland, so in several years you can kiss goodbye to XFCE, FVWM, BlackBox, FluxBox and any WhateverBox. And we, we are on verge to remain with a single desktop solution: Wayland/Plasma5 so we like or not, we should tame it. Accepting constrains like "not running at all as root" , will result on restraints of our freedom to use our own box as we like. |
You will still be able to compile xorg server and other desktops by yourself.
|
Quote:
However, how much useful will be that XFree86 server, even you manage to compile it, with its code rotten by many years passing over it? Same will happen sooner or later with the Xorg server code, which now is basically on "preservation" and IF we ignore this, we risk to have the surprise that someday Slackware will have a single functional desktop environment: Wayland/Plasma5 and that also we are gracious locked away from the root account. For our own protection. |
Quote:
My proposed patch is for Wayland/Plasma5 which is now fully locked for root and the main intention is to make it to behave similar with the better known X11/Plasma5. However, I have no intention to rehash that old thread of Darth Vader about "admins on Pampers" BUT I agree regarding one thing: let's do not consider the users some idiots who need to be protected from themselves. An user who legit have the root credentials can mess already in many ways with the system, even without logging graphically as root. BUT, the ability to run a desktop as root has its merits, for example I use this way on my rescue systems who are full Slackware installations on external USB hard drives. I have two and their purpose is full access to other systems. Read: administration. Another legit usage of a root desktop could be when the encrypted /home refuses to mount. This could happen and happened, and not so long ago to someone forum member. What should do that particular user who have at disposition only the root account? To post on LQ for help from console with Links? I believe that there are many cases of legit usage of a root desktop, that's WHY we should NOT agree with those blunt lockdowns of root account. And BTW, how many threads you seen on this forum from people who damaged their systems because they ran desktops as root? I am there on the last 10 years but I do not remember to seen one, if any. Maybe this happens because the Slackware users are particularly smarter and they do not need a babysitter? |
Quote:
|
Quote:
|
nvme, overlay, mkinitrd
Hi,
1. Please add nvme-cli (nvme) and overlay.ko to setup's initrd. 2. When running mkinitrd -h it loops forever (probably in args parsing loop). Cheers! :-) -- Best regards, Andrzej Telszewski |
Grub is not working since the latest upgrade (build 3) for bios legacy installations (it may also affect mbr), it just cannot be installed.
When executing: "grub-install /dev/sdX" the error says: Code:
Decompressor is too big You may want to take a look at: https://www.linuxquestions.org/quest...ml#post6221162 ... And also: https://www.linuxquestions.org/quest...ml#post6221247 |
@LuckyCyborg, I think that all this is not much relevant, also because for example there is Gnome3 which also compiles with Wayland. I think also step by step other desktops will move toward this direction if it shows that Xserver is really out of the game, in any case
it is not so much relevant imho. At the end we talk about few years in the future. So I think that if you start today with a slackware 15 you will have a usable platform for many of the softwares out there. I am still writing this from a Slackware 14.2 and running my business mostly on it, so for me it works quite well. Although I have to admit it, that this slackware release cycle took a really long path and not expected it would took so long at least few years ago not. But lets take it positivley, we will still have many options in the future. ;) |
I post a patch for grub problem , but i test and not works here , i remove message , sorry.
|
@LuckyCyborg You are excused :D I'm not too interested in a big back and forth on the issue, but I stand by disqualifying graphical root logins as basically a good thing™. Up to the Slackware people what they want to do about it.
|
|
why last 'grub-2.04-x86_64-3.txz' package, contain these files, in /usr/lib64/grub/i386-pc/
boot.img, cdboot.img, kernel.img, lzma_decompress.img, boot_hybrid.img, diskboot.img, lnxboot.img, pxeboot.img, i think, these files are not part of grub !? these files break the command 'grub-install /dev/sda' grub-install*: erreur*: Le décompresseur est trop grand. these files are no present in the precedent, 'grub-2.04-x86_64-2.txz' package, and probably are not part of grub. the old 'grub-2.04-x86_64-2.txz' package, work fine here, and no contain these files. |
Quote:
|
Bluez 5.56
Source: https://mirrors.edge.kernel.org/pub/...ez-5.56.tar.xz Change log: https://git.kernel.org/pub/scm/bluet...tree/ChangeLog |
This is a pretty minor thing, however on every package update it is easy to overlook it: would it be possible to add a bash completion symlink creation step to the git package?
Something on the line of: Code:
ln -s /usr/doc/git-VERSION/contrib/completion/git-completion.bash /etc/bash_completion.d/ |
libinput 1.17.0
https://lists.freedesktop.org/archiv...ry/041733.html |
gtk+-3.24.26
https://download.gnome.org/sources/g...3.24.26.tar.xz gtkmm-3.24.4 https://download.gnome.org/sources/g...-3.24.4.tar.xz gexiv2-0.12.2 https://download.gnome.org/sources/g...-0.12.2.tar.xz |
binutils 2.36 breaks "ar clq"
https://bugs.debian.org/cgi-bin/bugr...cgi?bug=981072 I just hit this trying to build nx-libs... |
bug: lrzip and minicom share usr/bin/lrz
1 Attachment(s)
Hello,
lrzip and minicom both install usr/bin/lrz but the two commands are very different and should be kept away from each other. I fixed the minicom slackbuild, but my patch may be too drastic. Regards, |
Quote:
But, yeah, I don't like where the whole Open Source/Free Software community is heading to - lack of sanity and too much self confidence for my taste on way too many places. Perhaps that comes for a reason - back in the day one had to do quite substantial amount of footwork before even standing a chance to make any reasonable code - nowdyas all one has to do is install a suite; enable few plugins mirror a repo out there and just start tweaking/twiddling an half baked project on and on... Back in the day people started from the ground - nowdays it seems as if newbies stat from high above the clouds already, and it shows IMHO. |
Quote:
"Slackware makes absolutely no assumptions about how you use the system" From this to fully blocking the most powerful user to use a particular desktop environment as he/her likes is a long way, isn't? I think that's one thing to recommend, to explain, to educate that some actions may be dangerous and it is entirely another thing to lock down software. I've just tested "startkwayland" as root. This Wayland/Plasma5 did not even start as root, even it works well as a regular user. So, I ask you: who is the owner of my own computer? Me or Slackware? |
Quote:
Yes, he's patched kate and konqueror (or was it dolphin or both, I can't remember) to allow root usage, but opening single GUI applications as root are a far cry from a whole WM/DE. The potential security implications are far higher running everything as root compared to a single program here or there. Quote:
|
Pat,
Please consider a built-in Slackware way for a user ~/.xsession-errors file. I think Slackware is the only distro I have used not directly supporting the log file. Perhaps the file could be user-defined and enabled/disabled in /etc/default/xsession-log or something similar. Possibly using /etc/xprofile. Or in an /etc/X11/Xsession file. Would be nice, that's all. Thanks. |
Pat,
Proposed patch for the hplip package: Code:
diff -urN hplip-3.20.6/hp-uiscan.desktop.in hplip-3.20.6.new/hp-uiscan.desktop.in Thanks. |
Quote:
|
Quote:
Code:
ln -s /usr/doc/git-$VERSION/contrib/completion/git-completion.bash $PKG/usr/share/bash-completion/completions/git |
Quote:
|
S-nail bugfix release
https://lists.sdaoden.eu/pipermail/s...ry/001401.html https://ftp.sdaoden.eu/s-nail-14.9.22.tar.xz This addresses some issues which came up after everything was rebuild here against glibc 2.33. |
Quote:
Quote:
I think we already added too much noise to this thread, but for what it's worth, I don't even want to see patches enabling root for Dolphin/Kate, I'm totally fine with upstream's stance on it. But then again, it's not that big of a deal what gibbons think either! |
CMake 3.19.6
https://blog.kitware.com/cmake-3-19-...-for-download/ https://github.com/Kitware/CMake/rel...-3.19.6.tar.gz GNU Nano 5.6 https://www.nano-editor.org/news.php https://www.nano-editor.org/dist/v5/nano-5.6.tar.xz Thunderbird 78.8.0 https://www.thunderbird.net/en-US/th.../releasenotes/ https://www.mozilla.org/en-US/securi...s/mfsa2021-09/ https://ftp.mozilla.org/pub/thunderb....source.tar.xz Edit: Are now available in -current according to the latest ChangeLogs: Quote:
|
...please disregard. Got duplicate posts yesterday.
|
Quote:
|
Quote:
against packages which on the same run will be replaced. For me it would feel better if extra-cmake-modules would be moved to d/, as phonon was already moved out of kde/ and needs extra-cmake-modules as build requirement. Code:
--- /source/kde/kde/kde.SlackBuild 2021-01-08 01:59:19.329008936 +0100 |
Quote:
https://www.linuxquestions.org/quest...ml#post6205270 |
Pat,
Proposed rc.6/rc.K patch: Code:
diff -urN sysvinit-scripts/scripts/rc.6 sysvinit-scripts.new/scripts/rc.6 |
Pat,
Some people might want sysctl stdout spew during the boot and some might not. Having an /etc/default file allows easier administration without editing the rc.S script. Proposed patches: Code:
# /etc/default/sysctl Code:
diff -urN sysvinit-scripts/scripts/rc.S sysvinit-scripts.new/scripts/rc.S |
Pat, Proposed rc.httpd patch:
Code:
--- rc.httpd 2021-02-24 17:21:50.145953292 -0600 |
Pat,
Proposed rc.inet2/rc.sshd patches for consistency with other rc.d scripts: Code:
--- rc.sshd 2021-02-24 17:38:04.400663336 -0600 Code:
--- rc.inet2 2021-02-24 17:41:55.646537017 -0600 |
All times are GMT -5. The time now is 11:29 PM. |