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.
Having worked extensivly with a program that used Microsoft SQL, it tended to create alot of problems and issues (in Windows). Solving MS SQL issues in Windows can be highly complicated and frankly extremely frustrating. Porting and using it on another operating system would be unwise, and I would highly recommend avoiding it, if possible.
You could have a look at GUIX, it's a package manager (and a distro too) that can be installed on most GNU/Linux systems, and it automates package management. It's not a normal package manager either, if you install it in Slackware it will seperate itself and the installed packages from the rest of the system, as far as I understand.
It's probably not so easy to install, but if you or your friends want easy access to packages on Slackware it's something to consider.
I tried this as a solution to the lack of some of the larger modern packages missing from slackware. It was ... incredibly fragile.
There is a lot of documentation but it assumes you already know how it works and a lot more besides (scheme and their particular version of scheme, i.e. all the many forms/macros). Customisation requires delving deep into scheme-land including learning incredibly complex and not very well documented macros (you basically have to search functions in emacs), and there's some weird impedance mismatch going on between 'this is the global system config of packages' and 'this is the packages i added by command'. That wasn't actually all too bad because it's just 'learning curve' but then I hosed the installation multiple times because i ran one of the update commands as root, and well whatever I did wrong it just broke everything repeatedly so I just gave up and got rid of it entirely. There were also some compatibility issues with slackware specifically - the guix documentation claims you can just install it on any system but that claim just isn't true, gcc and glibc versions affect it and at one point slackware current's libc was too new for it to work. The guix command is also extremely slow (makes slackpkg or even gentoo's emerge seem like speed demons, and i don't mean the compilation stages), and finally the developers really just aren't very nice or just have communication issues (perhaps english as a second language?), they got cranky when i had the audacity to ask about building things without pulse audio, or the fact everything breaks if you don't have x32 support in the kernel for the only-32-bit statically linked bootstap tools. I also tried nix a few times and that just installed packages that didn't even work to start with e.g. blender which is one of the programmes i was trying to get hold of would just crash on startup, possibly libc/stdc++/gcc compatibility issues again.
The good thing about it is that it isn't very hard to setup (it just takes a while to run) and is very easy to completely purge (remove /guix or whatever its, plus some env vars), so maybe others will be luckier than I was.
I tried this as a solution to the lack of some of the larger modern packages missing from slackware. It was ... incredibly fragile.
Hmm, that's interesting. I haven't tried it like that, I've only tried it in the GUIX distro. It is a weird thing, and I could't really wrap my head around it, but it is also a clever idea and a good concept.
But well, I guess that leaves you with the various options of community packages for Slackware, and if something is missing it's not unheard of that someone will package something for you if you ask nicely
I'm not really into slackware packages and pre-done things myself, I prefer to do it myself, and that's one of the reasons I got back to Slackware, so I can't exactly tell you much about it or where to find it and the alternatives. But there are 3 that I've heard of.
I tried this as a solution to the lack of some of the larger modern packages missing from slackware. It was ... incredibly fragile.
There is a lot of documentation but it assumes you already know how it works and a lot more besides (scheme and their particular version of scheme, i.e. all the many forms/macros). Customisation requires delving deep into scheme-land including learning incredibly complex and not very well documented macros (you basically have to search functions in emacs), and there's some weird impedance mismatch going on between 'this is the global system config of packages' and 'this is the packages i added by command'. That wasn't actually all too bad because it's just 'learning curve' but then I hosed the installation multiple times because i ran one of the update commands as root, and well whatever I did wrong it just broke everything repeatedly so I just gave up and got rid of it entirely. There were also some compatibility issues with slackware specifically - the guix documentation claims you can just install it on any system but that claim just isn't true, gcc and glibc versions affect it and at one point slackware current's libc was too new for it to work. The guix command is also extremely slow (makes slackpkg or even gentoo's emerge seem like speed demons, and i don't mean the compilation stages), and finally the developers really just aren't very nice or just have communication issues (perhaps english as a second language?), they got cranky when i had the audacity to ask about building things without pulse audio, or the fact everything breaks if you don't have x32 support in the kernel for the only-32-bit statically linked bootstap tools. I also tried nix a few times and that just installed packages that didn't even work to start with e.g. blender which is one of the programmes i was trying to get hold of would just crash on startup, possibly libc/stdc++/gcc compatibility issues again.
The good thing about it is that it isn't very hard to setup (it just takes a while to run) and is very easy to completely purge (remove /guix or whatever its, plus some env vars), so maybe others will be luckier than I was.
By that time extracting a freshly downloaded blender archive in opt and linking a launcher to it's wrapper script sounds like a walk in the park!
Not to mention downloading AppImages for whatever onto a non-noexec storage location, flipping the exe bit and launching them from there...
...
The RTC emulation option will be left off though as that seems pretty clearly bogus.
On my old dual-core-celeron laptop, the desktop feels more fluent with the introduced "CONFIG_RTC_INTF_DEV_UIE_EMUL is not set",
might be very subjective.
Files installed to /var/log/setup/ instead of /var/lib/pkgtools/setup
Several packages missed the /var/log/setup -> /var/lib/pkgtools/setup transition. Not a huge problem because of the compatibility link, but should probably be fixed:
I just did a rootfs on lvm lv, on encrypted pv install and my rootfs was /dev/sysvg/lvslack150.
When I got to the dialog for selecting the rootfs to use, the display field was truncated to /dev/sysvg/lvslack15. It still worked, but this might make it a little difficult to identify next time, when I possibly have a /dev/sysvg/lvslack151 as well.
May I suggest extending the display width of that field to allow for these longer block device names.
Few years ago while installing 14.2, I had an install issue in an UEFI setup with two hard drives. I got help here in the forum and found a workaround. I don't remember formally submitting a setup specific feature request in the "suggestions for 15.0" thread, which very likely means I never did, as well as that nobody else did either. And now when installing 15.0 in VirtualBox for the first time, I see that the problem persists and the expected feature is missing. No big deal, I can use the workaround again, but I'm posting here to make sure Pat sees it this time (unless that happened, feedback was provided and I somehow missed it).
TLDR: When installing 14.2 (and now 15.0) on an UEFI setup with two hard drives, the setup detects the EFI partition on the first drive and proceeds with it. As the forum post quoted above suggests, it would be nice if the setup would let the user to select the EFI partition it wants to work with, if it detects more than one on all drives it can see.
Few years ago while installing 14.2, I had an install issue in an UEFI setup with two hard drives. I got help here in the forum and found a workaround. I don't remember formally submitting a setup specific feature request in the "suggestions for 15.0" thread, which very likely means I never did, as well as that nobody else did either. And now when installing 15.0 in VirtualBox for the first time, I see that the problem persists and the expected feature is missing. No big deal, I can use the workaround again, but I'm posting here to make sure Pat sees it this time (unless that happened, feedback was provided and I somehow missed it).
TLDR: When installing 14.2 (and now 15.0) on an UEFI setup with two hard drives, the setup detects the EFI partition on the first drive and proceeds with it. As the forum post quoted above suggests, it would be nice if the setup would let the user to select the EFI partition it wants to work with, if it detects more than one on all drives it can see.
This brings back memories of WindowsNT and its bootloader NTLDR , I would notice similar behavior - it would just arbitrarily place the bootloader on a second partition or on a second hd, rather than just putting the bootloader on the first partition of the first disk - and as far as I knew there was no way to tell Windows NT where you would like to place it, it decided for you which was annoying.
May I suggest the KDE source tree migrate to the organization of groups directories on invent.kde.org? It is difficult to build one kde application using the somewhat obtuse old build scripts (applications, applications-extra, frameworks, plasma, plasma-extra). Far easier to get the latest tagged source for KWayland on https://invent.kde.org and build from Cmake-GUI than to adapt the blanket everything at once scripts for one application. For example: Plasma, Games, Graphics, Office, Education, Libraries, System, etc. All of the other source trees build individual packages, why not KDE? There may be historical reasons for keeping the old kde build structure of which I'm unaware, only a suggestion.
[I'm building the source tree using "-O3 -march=znver1" to see if I can make things zippier, if zippier is the word for which I'm searching.]
Last edited by hpfeil; 02-07-2022 at 12:58 PM.
Reason: added reason for suggestion
May I suggest the KDE source tree migrate to the organization of groups directories on invent.kde.org? It is difficult to build one kde application using the somewhat obtuse old build scripts (applications, applications-extra, frameworks, plasma, plasma-extra). Far easier to get the latest tagged source for KWayland on https://invent.kde.org and build from Cmake-GUI than to adapt the blanket everything at once scripts for one application. For example: Plasma, Games, Graphics, Office, Education, Libraries, System, etc. All of the other source trees build individual packages, why not KDE? There may be historical reasons for keeping the old kde build structure of which I'm unaware, only a suggestion.
[I'm building the source tree using "-O3 -march=znver1" to see if I can make things zippier, if zippier is the word for which I'm searching.]
Ever tried building a single package like this? For the kwayland package:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
