@offgridguy
Unfortunately Slackware derivatives suffer from same issue: small repositories. Using SBo and third party Slackware repositories is not easily possible for these distros. Soon or latest you will miss some packages that you can't install or build on your system without headache.

Salix tries to solve this issue using modified SBo for slapt-src but still it doesn't benefit from alien or other third-party binary repositories designed for Slackware.

If you want a more ready to use Slackware based system fully compatibile with SBo and third party binary repositories, use MLED.

http://www.microlinux.eu/

1 members found this post helpful.

I gave Zenwalk a spin once, a long time ago. The project's scope is similar to what I expect from a Slackware-based desktop, e. g. based on Xfce, one-app-per-task and no-bullshit. Unfortunately, I found Zenwalk to suffer from the same shortcomings you find in so many projects. At the time (around 2006 IIRC), the Zenwalk team churned out new releases in a frantic cycle without giving any thought about perennity, which meant you were supposed to do a major upgrade every three months, sometimes even more frequently than that. And they didn't care much about publishing their source tree. I don't know if that's changed since.

Thanks for your feedback kikinovak I hope that you will try it soon. beta2 is already as stable as a pre-release current can be...

The spirit of the project as it is now in 2016 is in fact very close to the Minislack spirit : keep the Zenwalk improvements, but without forking : "Everything in Zenwalk is vanilla Slackware at system level" : ISOs releases are following Slackware cycle.

For the beta3, appart of packages updates (Chromium, Libreoffice, libs...) the main work in progress is "under the hood" : move some desktop configurations (like user creation for example) from "post-install, at first boot" to "setup stage" (before first boot).

A discussion with Slint team is also on the way to share some ideas between projects ...

Cheers
JP

I must have tried every Xfce-based Slackware derivative under the sun for the last ten years. Wolvix, Zenwalk, Vector, KateOS, Salix, etc. Many of them had some excellent ideas, but at some point, there was always some detail that I wasn't happy with. LibreOffice too recent, Ristretto too old, Brasero not build against totem-pl-parser so it couldn't handle playlists correctly, weird choice of default artwork, sources not available, buggy installer, confusing website, gslapt fetching the whole kitchen sink when trying to install a desktop plugin, etc. (I'm mostly talking to you, Vector.)

Maybe I'm too much of a control freak myself, but after some time, I got a pretty good idea of what I wanted and what I did not want, so I started my own little project, not as a separate distribution, but explicitly as an addon to Slackware Linux, meaning no separate ISOs. I'm a happy camper now, and the project seems to be steadily gaining momentum.

Cheers from the sunny South of France, and a friendly shoutout to the Zenwalk team.

Niki

Very interesting, I had not heard of Microlinux before now. Sounds appealing, definitely worth a look.

sorry Travis, but Alien's multilib is working fine on Salix-64. They even have instructions on how to do so.

1 members found this post helpful.

Yes, but I didn't talk about multilib which is a special repository. By the way, seems that you forgot Gapan's recommendation about multilib http://forum.salixos.org/viewtopic.p...ilit=antivirus

Anyway, I like salix philosophy and IMO Salix devs have done great job to bring compatibility with SBo. There are some bottlenecks for Iranians to use it, But I am an occasional user of Salix openbox and it's great.

If Salix has small repositories, and Salix offers double the amount of packages that Slackware does, what does that mean for Slackware?

Using SBo is easier in Salix than it is in Slackware. Salix provides tools that automate building and installing packages from SBo out of the box. Slackware doesn't.

I'm not sure what you mean by "headache". But if you mean that installing stuff from SBo for Slackware users is trouble-free, it isn't. It mostly is trouble-free, but it isn't completely trouble-free. Same as in Salix.

Slackware does not benefit from alien or third-party binary repositories either. I mean, of course anyone is free to grab packages from them and use them, but slackware itself does not provide any means to do that, it certainly doesn't utilize them by default and installing packages from other third-party binary repositories is not supported by Slackware ("supported" as in: it's not PV's fault if something breaks you system). Salix is no different than that.

What about it? In my opinion, multilib is ugly and there are better solutions for running 32bit apps in a 64bit system. And it's just as ugly in any other distribution. And I'm genuinely happy that Slackware went the pure-64bit way. And it is my understanding that PV has the same opinion (but don't quote me on that), otherwise he would have added multilib by default in Slackware.

6 members found this post helpful.

I think his only point in mentioning that is that most of those 3rd-party binary repos expect a full Slackware install and list required dependencies accordingly. With Salix, it is possible to run into dependency issues that aren't documented in these 3rd-party repos because something that exists on Slackware is missing on Salix. I have no idea how common it is, but it is definitely possible.

Of course, Salix does provide more methods out of the box to get 3rd-party software, where with Slackware, you need to download and install a 3rd-party program to be able to install from other sources (short of you downloading directly from those sources and installing manually), but Slackware wasn't intended to have that ability out of the box.

Of course it's possible. That is also the case for any less-than-full Slackware installation. But Salix has mechanisms to overcome that. Any missing dependency is fixed, as long as it is reported. Not to mention that in order to not have any problems with 99% of SlackBuilds at SBo, a single command can be used:
(replace slackware with slackware64 for x86_64).

Absolutely agree. But then again, why some people think that Salix should support every 3rd-party binary repository for Slackware out of the box is beyond me.

1 members found this post helpful.

Yes, But Slackware doesn't depend on automated package managers to build and install packages. By a full install users can manually get and install them and their few dependencies from other sources designed specially for Slackware. Salix doesn't give such a freedom to users. Simply, It follows Debian approach for package managing without huge Debian repository.

Easier? maybe. But I (and surely other Slackware users) don't think this automate building is an advantage over Slackware.

Not only SBo. What if Salix users want to install a package on their low-hardware system without a time consuming approach to build and install it and it's dependencies (I guess you provide openbox and fluxbox editions for those systems)? Are they be able to get and install them from Alien or slackonly repositories without headache?

Yes, Slackware doesn't support third-party binary repositories but, They support Slackware and unfortunately they don't support Salix/Zenwalk/Vector/Slackel. As I said before third-part binary repositories would be useful for those who want rapidly grab and install huge packages on their system. Of course this is not PV fault if they break their system as this is not your fault if Salix users break their system by automated building packages from SBo.

Well, I am not the right person to talk about multilib pros and cons.

Anyway, As I said before in Salix forum, personally I encourage Iranian Ubuntu fans to use Salix and If you remember I request supporting sbosrcarch by slapt-src for those users. But, after trying several distros I found out that this automate package managing is not a good thing for those who are not "lazy" and with respect to this issue MLED has merit over other slackware derivatives.

Of course it is. That's one of the reasons why Salix has developed slackware repository with dependency support. See also the warning at the end of this page. and this other one.

This is where Slint 14.2 will come into play (I hope).

PS Of course each distribution has its pros and cons, some prefer A, other B. That's probably one of the reasons why there exist several

1 members found this post helpful.

I'm not discounting the work you've put into Salix. I've referred to your dependency information for the official packages many times. However, Slackware recommends a full install, and most 3rd-party repos expect that, so if a user decides to not follow the recommendations, they will have to figure out those dependency issues themselves. A Salix full install will still miss some Slackware software, which could result in expected/undocumented dependencies in these 3rd-party repos to not be met. Since the package maintainers expect a full Slackware install, those official Slackware dependencies won't be listed, and it'll be an exercise for the end-user to determine what is missing and to install it (you are correct that most would be resolved by installing the d/ and l/ series, but I doubt this is presented to the user when builds fail, and even then, it isn't guaranteed to fix their problem).

I certainly don't think that. You've done some great work in supporting many things (especially the massive SBo)... no one should expect you to support them all (even though some still might). But, that doesn't mean that it isn't an issue for some that you don't provide additional dependency information for some 3rd-party repos.

That doesn't help in a 3rd-party repo that expects a full installation. Most of those repos will not list required dependencies that exist in a full Slackware install. Anyone who isn't running a full Slackware install (whether a trimmed official version of Slackware or one of the distros that do it for you) will most likely run into undocumented, required dependencies at some point. This doesn't mean people shouldn't run trimmed versions of Slackware or one of these other projects, but the issue of 3rd-party repos not providing official Slackware dependencies will continue to exist and cause the occasional problem for these users not running a full install.

2 members found this post helpful.

Many users use Salix due to it's minimal approach for Slackware installation. What is the advantage of Salix over MLED if users have to install all Slackware libraries? automated package manager? MLED users can have it if they want (I compare Salix with MLED as they are more ready to use than pure Slackware).

No, Simply Salix needs bigger repository. I know that means bigger dev team and package maintainers and needs a lot of work but, that is the only choice if Salix wants to remain as minimal automated distro for lazy slackers.

Neither of them 'depend on automated package managers' and they're both perfectly usable without any repository.
Please cite the sources 'designed specially for Slackware' that won't work on Salix, otherwise this is FUD.