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.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

I'm wondering if anyone has any information on what's going on with linuxpackages.net? Since the turn of the year (2009), it seems that the quantity/quality of the packages on linuxpackages has declined remarkably. I'm submitted two packages (deluge 1.1.8 and 1.1.9) and their status has just disappeared into the ether. I've also noticed that a previously regular and large package contributor, Ken Zalewski, (as well as number of formerly large contributors) has stopped contributing. Anyone know why? I know and realize there are other (most likely, better) package repositories (and I've moved more on to just doing packages from slackbuild), but linuxpackages was once one of my ports of call for slack packages. It'd be (in my opinion) a sad day if that site were to fade into oblivion.

I've got to agree with dasx. All tho slackbuild is superior to linuxpackages, it is a great offer to new users. I started using packages from linuxpackages when the compilation failed and I was unaware of slackbuilds. Just because someone don't like it, doesn't mean its a good thing they are going down.

I haven't used linuxpackages.net in a couple of years. However, at one time that site offered me something slackbuilds.org does not: compiled packages.

Providing complete packages is against the philosophy of slackbuilds.org, not to mention the additional storage costs and download bandwidth. Yet if linuxpackages.net disappears then the only large repository with compiled packages would be slacky.eu. I wrote large repository, not only repository. Now that slacky.eu is no longer maintained in English (Italian only), navigating that site is cumbersome for those who do not read Italian.

Only a few years ago neither slackbuilds.org nor slacky.eu existed. The linuxpackages.net site served the Slackware community. Many people do not want to build packages. Some people, like me, do not learn to build packages for a while yet they nonetheless want certain packages. Many people do not have the computer muscle to build the large packages. For many years I had such old hardware and could not build such packages even if I knew how or wanted. These days I search for build scripts to compile packages but not in my early days of Slackware. Having a large central repository of compiled packages is nice for many people.

Yes, many Slackers prefer to compile their own packages, but not all. People use Slackware for a variety of reasons. Not all users want to build packages. Not all users have the time or computer horsepower to build packages. The lack of a readily available large central repository is always in the list of reasons why many people do not use Slackware.

My only complaint against linuxpackages.net is the lack of a requirement to include the build scripts with all packages. Not doing so tends to create issues of mistrust and uncertainty. Regardless, I think linuxpackages.net serves a purpose and seeing the site disappear would be unfortunate news.

Now that slacky.eu is no longer maintained in English (Italian only), navigating that site is cumbersome for those who do not read Italian.

I don't find it cumbersome. I just type name of the package I want into the search box in the top left corner. Then I get either a download link or what's obviously a "not found" message. That's all the navigating I need to do there

Quote:

My only complaint against linuxpackages.net is the lack of a requirement to include the build scripts with all packages

They also did not require their packages to be built on clean systems. That was a problem too.

They also did not require their packages to be built on clean systems. That was a problem too.

That is my one complaint about linuxpackages.net. Quality control. I doubt the integrity of the packages provided at that site.
I don't have a problem with downloading, installing pre-built packages. However, I will only download, install packages from a few trusted sources. The links in my signature are trustworthy in my opinion.

I have used linuxpackages.net in the past (before SlackBuilds.org started and before I knew about slacky.eu) and have had some problems with the quality.

Now I prefer SlackBuilds and compile my own packages.
If I can't find it on SlackBuilds.org I check slacky.eu but I still compile my own packages, as I am testing everything on Slackware64.

I think there is a need for a compiled-packages repository, as not all users want to compile their own applications.
If there is a need to have it in English or any other language, someone will have to stand up and offer to do the localization. That's the way it works with open software.

When i started to use slackware i used linuxpackages but i soon stopped because of the lack of quality.
I remember strange ownership/rights and not build on cleansystems and missing build scripts, i even think that linuxpackages had some own tools or base when they made there packages and that made the few existing SlackBuilds not so great.
Now i only use SBo and sbopkg, but i can understand that some people want compiled packages.
So why don't some of you contact the team behind linuxpackages and start cleaning it up and write rules for packages or start a new project?
I remember using swaret and linuxpackages in my early slackware days (but i can't understand why i did it).
These days i would never install any package from linuxpackages.

Well, idk about LinuxPackages.net but I LOVE Slackbuilds, idk, I can't get their slack packages to ever work though so I just download the source and compile them all and it works fine, anyone else have to do the same thing?

I suppose I will the contrarian on this thread and go on record that, in my experience, linuxpackages.net does fill a need that slackbuilds.org cannot: providing a repository of compiled packages for large applications, particularly ones with *lots* of dependencies.

I use mostly old hw or a wimpy netbook with little storage, memory and cpu power, so I try to avoid compiling the big stuff. And I've never experienced the quality issues so many pointed out here.