SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
All of the source regular-file perms are 770 or 660; they are
not being caught by talloc.SlackBuild.
Pat, in case you are noticing a pattern to my recent posts; I'm
*not* intentionally hunting nitpicks; I'm working on my Slackware
documentation system and running into the issues.
And that's perhaps the issue - we can repack the prebuilt with our local "ports like" sbotools no problem.
But to ship a binary usually assumes it is built from source - and that might have some issues to start with - not once did i end up using a prebuilt binary because i would fail to build one my own.
I guess so. The binary repackaging SlackBuild from SBo could be installed with whatever tools, but presumably Pat would want to build from source for Slackware, and I guess it's a pain somehow.
I would like to see changes with all of the sleeps and pauses in the rc.d scripts. They made sense in the days of inferior hardware. Most if not all of the delays seem unnecessary these days.
As a comparison, at work I support other distros and reboots/halts are much faster.
--- rc.K 2020-01-12 13:41:19.052749177 -0600
+++ rc.K.new 2020-01-12 13:46:38.728771952 -0600
@@ -14,6 +14,11 @@
# Set the path.
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin
+# Load a custom screen font if the user has an rc.font script.
+if [ -x /etc/rc.d/rc.font ]; then
+ . /etc/rc.d/rc.font
+fi
+
# Load any needed keyboard mappings:
if [ -x /etc/rc.d/rc.keymap ]; then
/etc/rc.d/rc.keymap
I think I might've asked too much in previous posts, but forgot... like maybe asked to add too many X window managers (WM) or desktop environments (DE.) Those were merely suggestions of things to consider, but not essential. I know people became extremely frustrated with KDE since some of the earliest versions (people even liked 0,1,2 more than some things about 3, but generally liked 3 more than 4,5) and now some people even argue various newer WMs/DEs are lighter than XFCE. I still use a fast enough PC that I use KDE, but if CDE becomes more usable in the future, I will definitely switch, even if I must compile it myself... doesn't matter though. I even like using twm on servers and occasionally on desktop for quick sessions. I care more about Slackware as the best programming/development/command-line OS than anything related to GUI (just a convenience.) Of course I hope KDE5 will finally work without the various bugs/slowdowns/crashes/halts (and it is usually usable without slowdowns/halts on other OSes) because I'll probably end up using it a bit even if CDE becomes better than KDE... just at this point I almost could not care less about GUIs... they've always been a mess... if KDE5 is ready, it'd feel like a big enough change to use the number '15.0'... if not, I might not even care. I just wish there was a fast, usable GUI like a combination of Windows 3 (program groups) and 9x/ME (start menu) without too many fancy things, like no forced animations, but with KDE conveniences like system-tray w/volume & w/clipboard, pinned/disappearing/reappearing panel ‘launchers’ (option to pin when you right-select a program on taskbar,) gradient background, and some system-tray 'widgets.' I'm not guessing minimalist KDE or something better may ever be possible in the future unless you compile it yourself.
A few more suggestions I have are the following (all SBo builds) and maybe the rest of bsdgames (Rogue, also on SBo, etc.) could be added to the core distribution.
beep (Unix command to make PC speaker work properly)
Network UPS Tools (NUT)
sshpass (give your password as a flag to login to SSH such as if you have problems with keys or password is required)
On the other hand I also don't care so much whether more popular (i.e., evolved from C++, like Java, C#/Mono) object-oriented programming languages (such as I suggested, and others) are added or not... it might be useful for future projects but of course probably always can be added from SBo. I only truly enjoy asm and C (and I admit, BASIC, but I don't use it anymore and I understand the professional criticism of it.) When I mentioned type-safe, also type-strong is important and apparently are separate things. Apparently some classic languages already available on/for Slackware (or SBo) have one or both (Common LISP, etc., and definitely other classic ones that have one or both.) I know some newer ones have one or both but I consider all of them a huge mess with other problems/inadequacies/risks. I'd have to reread some CS sources what the difference is and what classic languages have one or both features or what newer ones aren't the worst (I know ADA is one or both lists on Wikipedia but maybe not completely type-safe and is kind of obscure... possibly has a version in GCC or another Free/Libre/Opensource Software, FLOSS compiler, anyway.)
Distribution: Slackware on server, Bunsenlabs on desktop
Posts: 32
Rep:
Code:
a/nvi-1.81.6-x86_64-1.txz: Added.
This is an implementation of the classic ex/vi text editor written by Keith
Bostic. Due to this having UTF8 support which elvis lacks, we'll have it
take over the ex/vi symlinks if they aren't already pointing to a different
choice. Note that the removal of vi/ex symlinks from the elvis and vim
packages might cause your ex/vi symlinks to point to this after all the ex/vi
packages have been upgraded. You can set them to your preferences using
pkgtool -> Setup -> vi-ex.
Patrick Volkerding now has chosen nvi as the default UTF-8 vi compatible editor. A good choice.
Personally, I still heavily use Elvis for coding, scripting and configuring, when I know that only ASCII characters are used.
I forgot why I choose to package a binary only one, but I actually have created a build script from the source after reading discussion here, it builds after some small changes, but I have not a chance to test out the newly build binary yet.
Quote:
Originally Posted by SCerovec
And that's perhaps the issue - we can repack the prebuilt with our local "ports like" sbotools no problem.
But to ship a binary usually assumes it is built from source - and that might have some issues to start with - not once did i end up using a prebuilt binary because i would fail to build one my own.
Noto Color Emoji or some similar color emoji font should be included in the next version.
It exists in SBo and works fine. There's lots of colored emoji floating around everywhere these days. Having it work out of the box in Slackware would be best IMO
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
