Programs, what you like to see in Slackware tree

rkelsen · 03-11-2013, 06:36 PM

Quote:

Originally Posted by eloi

Now I know a lot about what the3dfxdude think Patick think

.

Hey Walter, slackware is a compilation of completely unmodified software packages. Anyone can download all of the relevant source code from the original author/s and replicate slackware with minimal effort. The design decisions you're complaining about are made 'higher up the tree'.

Quote:

Originally Posted by eloi

So if you still find Xfce more "unix like" than Gnome or KDE wait two years to change your mind.

I don't think anyone here is making this claim. The common sentiment seems to be that XFCE is less bloated than KDE, while retaining most of the functionality. Personally, I prefer KDE because it has a lot of little features which make life easier for me. eg: the ability to "drag and drop" songs off a CD into ogg files on my desktop.

Then there are "cosmetic" things like KDE's desktop effects which give the DE some personality. I don't use them on my older hardware, but have them enabled on my new laptop. Yes, they're a waste of resources but they make me smile.

Quote:

Originally Posted by eloi

Are you happy configuring your environment using an imitation (xfce4-settings-editor) of the imitation (gconf) of the beloved and widely *praised* Windows registry?

There is nothing like the Windows registry in Linux. You don't have to use either of the tools you mentioned in order to configure your desktop. XFCE, Gnome and KDE all use text files for configuration. You can edit them in any text editor.

volkerdi · 03-11-2013, 06:44 PM

Quote:

Originally Posted by rkelsen

Hey Walter, slackware is a compilation of completely unmodified software packages. Anyone can download all of the relevant source code from the original author/s and replicate slackware with minimal effort.

Thanks for the laugh!

rkelsen · 03-11-2013, 06:57 PM

Quote:

Originally Posted by volkerdi

Thanks for the laugh!

Hey man, I didn't mean to cheapen your efforts. Your work is well appreciated here, and has been for a very long time.

It surely is a lot of work to download, compile, install and configure everything to get it all working the way you do... I was merely trying to highlight the fact that you don't 'proprietarise' anything.

eloi · 03-12-2013, 04:29 AM

Quote:

Originally Posted by Didier Spaier

@eloi:

(3) If you think that known DE are going the wrong way (and you maybe right there to some extent), you still may invent a new one or fork an existing one.

If you read carefully what I posted on fontconfig mailing list
you may notice this link to my site:

http://roquesor.com/linux-7.php

Coherent with KISS and Slackware: a small effort in the right
direction is a bigger contribution that a humongous one in the
opposite.

(Personally, my ethic is not tied to meritocracy. Feel free to
mock me as usual. This forum needs a bit of humor sense like
yours).

Walter

H_TeXMeX_H · 03-12-2013, 09:24 AM

Quote:

Originally Posted by rkelsen

Hey Walter, slackware is a compilation of completely unmodified software packages. Anyone can download all of the relevant source code from the original author/s and replicate slackware with minimal effort. The design decisions you're complaining about are made 'higher up the tree'.

I was sure Pat V would strike you down where you stood using Bob Dobbs' lightning bolt he borrowed for a short while.

You got lucky this time I guess...

ReaperX7 · 03-12-2013, 09:42 PM

Slackware tries to avoid using as many upstream patches as possible, but it's not entirely without upstream patches. Most patches from the upstream that are used only are used to solve problems with other Slackware packages, and in fact all Linux distributions have patches for each package they release. Even Linux From Scratch has about a dozen or so patches for their packages, so you really can't use entirely true vanilla software. If you did, you might have a lot of issues ranging from simple incompatibilities to complex security holes.

ngc891 · 03-13-2013, 07:50 AM

Quote:

Originally Posted by Alien Bob

Reading that, why don't you evaulate those scripts you have written, and sumbit some of the more valuable ones (and that are not yet available on SBo) to the SlackBuilds.org project?
People who write SlackBuild scripts as routine and actually use the packages they produce, can add value to the Slackware community sites. Slackware is a small distro, and its community is important.

Well, it's not going to happen anytime soon. These slackbuilds were never planned to be published, so they:
- all contain hardcoded things and are not generic (I like my private slackbuilds small and neat)
- are mostly too old, for software I just tried a few times and then forgot
- were not all tested against the new slackware 14 or dependencies

And I don't talk about checking one by one all the files against what is in the SBo repo. All this is not fun and it's usually faster to start from scratch. As of the one for E17, they are not very different from SBo's one but are publicly available.

Quote:

Originally Posted by Alien Bob

But still, you should not call other people's work on scripting "cheap". Writing a SlackBuild script may not be a big effort, but after submitting it to SBo you will be expected to keep maintaining it, and interact with the people who use your script(s). That is the hard part, because the public submission creates expectations. We call you a "maintainer" instead of a "submitter" - those two are miles apart.

I agree that maintaining slackbuilds up-to-date gives more work. But as I said, I don't think SBo is the definite answer. For instance, compiling KDE could make the wisest tibetan monk start eating the walls (I guess you're not tibetan).

Quote:

Originally Posted by Alien Bob

As for feeding back improvements to upstream developers - I have had bad experiences myself with arrogant assholes who would not consider Slackware as a distro they had to take seriously, so I eventually stopped giving direct feedback and instead look for bugtrackers to register my issues.

Most devs don't care much about packagers. In some distro, the packagers sometimes overpatch the source code, and this can lead to some epic fail (like the infamous openssl package in Debian). I guess it make them quiet angry.

They don't care about Slackware? Well, maybe like 97% of linux users. Even people working on the core system don't care about us. Systemd is just one example among many others. If we want to keep control on our distro, we should federate our efforts and give more light on Slackware.

Quote:

Originally Posted by Alien Bob

And in response to the topic at hand: adding community packages to the Slackware DVD is something which should not be considered, is my opinion.

Never asked for this for a lot of obvious reasons. But having a community repository, managed by the community (Patrick Volkerding has surely enough work with the system) would be a way to federate our efforts. The only thing that needs to change in Slackware is slackpkg, it should be able to look for third-party repositories and someone already did the work with slackpkg+! I think we should think about this seriously (repo structure, server space, auth, etc). We have already many packages ready out there on several places and it would be very nice for people to just slackpkg+ their {Gnome, LibreOffice, TexLive, E17, last KDE, whatever}.

What do you think?

solarfields · 03-13-2013, 08:01 AM

Quote:

But having a community repository, managed by the community (Patrick Volkerding has surely enough work with the system) would be a way to federate our efforts.

how about slacky.eu?

hitest · 03-13-2013, 08:15 AM

Quote:

Originally Posted by solarfields

how about slacky.eu?

For third party software I prefer to go with completely trusted sources where the software maintainers have been thoroughly vetted. I trust Robby Workman and Eric Hameleers; their Slackware packages are completely trustworthy.

ngc891 · 03-13-2013, 08:29 AM

Quote:

Originally Posted by asamardzic

In this particular case, as a maintainer of SBo scripts for E17 and accompanying libs, I'll readily admit that my work on this was very cheap; but that's exactly because Eric and other SBo people have provided great foundation through script templates for various standard setups, and also because E17 people are sticking to very clean, vanilla autotools based build.

@ngc891: If you have any suggestions regarding these scripts, please let me know; or, even better, if you would like to take the maintenance over, you're more than welcome (I'd only suggest that you use SBo mailing list for all of your comments in that regard - this list is the place to discuss everything SBo related, and it's pure coincidence that I've encountered this thread here at LQ, as I don't read LQ regularly). I have no particular interests in E17 except that I'm an ordinary user over number of years; as nobody else popped up to provide E17 SlackBuilds, I've uploaded them couple years ago, and kept updating them since. Indeed I haven't bothered back then to Google for scripts provided on places other than SBo, but why should I - personally, I don't care about sites providing binary packages, and on the other side, having SBO template script readily available made creating these scripts very simple, so I had no need to peek into how other people would do it.

I'll try to take a look later.

Quote:

Originally Posted by asamardzic

Back on topic - I really hope that PV considers including Enlightenment back into official set of packages. E17 is pretty solid these days, is looking as good as ever, and practically there is no burden whatsoever in maintaining corresponding SlackBuilds. The only issue is that Enlightenment people are keeping corresponding foundation libraries split over 10 or so packages, but maybe these could be handled with single SlackBuild (@ngc891: or maybe you could try to exercise some of your influence to try to convince Enlightenment people to unify these in single build - if I remember it correctly, I think it was mentioned somewhere around E17 release that these libraries are going to be unified into single EFL package, but haven't happened so far).

It's already done in the repository. It will be published as the EFL 1.8 around april. The E repo migrated from subversion to git. I had already provided slackware build system for the svn version of E17. I'll update it and push it on git repo this week-end. As for E17, the git version doesn't look so good yet, better to stay with the 0.17 branch for now. What I can get on the E17 repo server is a VM to run Slackware for automatic compilation of packages. That would be very useful for me. Need to sort it out and other dev are still busy setting up other things for now. This will ensure E17 is working well on Slackware. Systemd is still carefully not required, but be sure I'll protest if it's happen :-)

hpfeil · 03-15-2013, 12:12 PM

I rise to address this forum with a Point Of Order.
"anti_user" started this 21-page thread early June 2011. His last post was last month. I suggest this issue is a drive-by troll.
The only person who should be asking this question is His Honor, Maestro Dr. Volkerding. I defer to his judgement.
What's it been 20 years? Who has the decades of experience required to suggest a change?
--
Troll Hunter

Alien Bob · 03-15-2013, 01:44 PM

You're missing the point of this discussion apparently.
I just wished the OP had a better grasp of english... it hurts my eyes every day I see this topic's title in the forum.

Eric

chrisretusn · 03-16-2013, 05:06 AM

LOL, nice to see I'm not the only one who winces at the title....

eloi · 03-19-2013, 07:15 AM

Quote:

Originally Posted by hpfeil

I rise to address this forum with a Point Of Order.
"anti_user" started this 21-page thread early June 2011. His last post was last month. I suggest this issue is a drive-by troll.
The only person who should be asking this question is His Honor, Maestro Dr. Volkerding. I defer to his judgement.
What's it been 20 years? Who has the decades of experience required to suggest a change?
--
Troll Hunter

Just one more important observation

We know that community driven development is a bit fake. Like
work groups at school where the nerd does the job. Emacs editor
is a good example of community driven software development. I
was an emacs user. I sent a bug report and I was answered
immediately and the bug was fixed. If you take a look to emacs
devel mailing list you will notice that just two guys do the
job, the rest (including rms) are there to chat and annoy.

But, being realistic, you need a minimum. A person or a group
can have the last word but you need users feedback and giving
feedback to users. I mean concise, rational, clear feedback not
disguised behind veils of mysticism and suspicious silences (the
typical military quarter atmosphere). Over all bug reports. Do
not expect your project be taken seriously without a clear
official place where to send bug reports to real maintainers or
having an outdated, unattended official site.

ponce · 03-19-2013, 07:19 AM

Quote:

Originally Posted by eloi

But, being realistic, you need a minimum. A person or a group can have the last word but you need users feedback and giving feedback to users. I mean concise, rational, clear feedback not disguised behind veils of mysticism and suspicious silences (the typical military quarter atmosphere). Over all bug reports. Do not expect your project be taken seriously without a clear official place where to send bug reports to real maintainers or having an outdated, unattended official site.

You aren't talking about Slackware, right? we are writing on the official feedback/bug tracker platform