Some thoughts about the future of Slackware

I.G.O.R · 07-01-2020, 04:44 AM

Quote:

Originally Posted by EdGr

I did not play the BSD games while I was at Berkeley. I never imagined that I would be unchecking the box in an OS installer nearly four decades later.

Yes, it's really funny. However, there is one thing which is not funny at all. Emacs and TCL are still in seperate groups. In 2020. It's just unbelievable.

solarfields · 07-01-2020, 04:46 AM

Quote:

Originally Posted by I.G.O.R

Emacs and TCL are still in seperate groups. In 2020. It's just unbelievable.

That's the least of my worries.

LuckyCyborg · 07-01-2020, 04:46 AM

Quote:

Originally Posted by I.G.O.R

Multilib is not officially supported. A lot of useful things are somewhere else, so 32bit support could be there too.

From what I remember, Mr. Volkerding explained very clear that when times will come to abandon the 32bit architecture, he would NOT go multilib, but the 64bit Slackware will continue as it is, then will continue to be pure 64bit.

In other hand, Mr. Hameleers explained very clear that he will NOT maintain a 32bit port of Slackware, to make the multilib possible, as it reuse the 32bit packages of Slackware. Hence, when Slackware will drop the 32bit architecture, he also will drop the multilib support, then Slackware will remain solely with the pure 64bit architecture support. And ARM.

Be careful what yo wish, people! Because there would NOT be multilib anymore after the 32bit drop on Slackware.

I.G.O.R · 07-01-2020, 05:01 AM

Quote:

Originally Posted by demifiend

rpm2tgz is still useful because many scripts on SBo don't build from source, but simply convert RPM packages to tgz for installation on Slackware.

Small correction. SBo scripts don't use rpm2tgz package (I hope). They use rpm2cpio command which comes from rpm package.

To be honest, no one should blindly trust rpm2tgz.

I.G.O.R · 07-01-2020, 05:17 AM

Quote:

Originally Posted by Gerard Lally

Probably just an eastern European directness and abrasiveness. I'm never offended by it, nor should anyone else be.

Russians are Eastern Europeans. I definetely should memorize this wisdom. I'm just learning new things every day.

I.G.O.R · 07-01-2020, 05:23 AM

Quote:

Originally Posted by EdGr

I have avoided replying to this thread, but your question deserves a reply.

There is a cost in keeping old software. It is mindshare.

As an extreme example, a new user looking for an image editor might fire up xv when he should have fired up gimp. Getting rid of xv eliminated a wrong choice for 99% of users, and the 1% who really want xv can still install it themselves. This is better human engineering because wrong choices are harder to make.
Ed

Isn't it that "xv" which on first run shows a splash that says "this is shareware"? OMG, it's still there.

hazel · 07-01-2020, 05:37 AM

Quote:

Originally Posted by LuckyCyborg

In other hand, Mr. Hameleers explained very clear that he will NOT maintain a 32bit port of Slackware, to make the multilib possible, as it reuses the 32bit packages of Slackware. Hence, when Slackware will drop the 32bit architecture, he also will drop the multilib support, then Slackware will remain solely with the pure 64bit architecture support. And ARM.

Be careful what yo wish, people! Because there would NOT be multilib anymore after the 32bit drop on Slackware.

And bang goes my printer! Its driver won't work without 32-bit glibc.

I.G.O.R · 07-01-2020, 05:43 AM

Quote:

Originally Posted by Gerard Lally

But Microsoft Word and LibreOffice Writer do not produce documents remotely near what TeX produces, typographically speaking, even though their mindshare is far greater. All TeX has been getting since the 80s is minor updates, while the office suites continue to get a constant stream of updates without ever coming close to producing typographically acceptable, never mind aesthetically pleasing, documents on a par with a TeX document. Better human engineering is better human engineering, no matter how few there are who recognise it.

I do not see analogy between xv/gimp and TeX/Office. It sounds like your "geography" about Eastern Europe.

I.G.O.R · 07-01-2020, 06:02 AM

Quote:

Originally Posted by enorbet

You guys promoting the ousting of older or "unmaintained" software have heard the cliche "If it ain't broke, don't fix it", right?

and...

Mindshare? I despise the entire concept of someone making decisions to "protect me from myself"... and I have severe misgivings about anyone doing that for anyone else. IMHO mistakes are a valuable part of learning.

I agree, but learning from mistakes with newer or more popular things is more valuable than learning from mistakes with obsolete or ugly garbage which can be easily replaced with something newer and/or better.

FlinchX · 07-01-2020, 06:05 AM

Quote:

Originally Posted by I.G.O.R

like this slur "GoToSBo"

I'm not an SBo contributor, so I'm in no position to speak for those people, but there's a great deal of effort involved to keep all those SlackBuilds functional and there's an update every week. But as an end user who benefits from it, I find that calling it a "slur" is at least disrespectful. And this is my last post in this thread, because this doesn't seem to be about the future of Slackware, to me it's rather about Slackware not being the way OP wants it to be.

kgha · 07-01-2020, 06:08 AM

Quote:

Originally Posted by I.G.O.R

May be because lilo project is itself abandoned?

(Ahem) https://www.linuxquestions.org/quest...7/#post5459873

I.G.O.R · 07-01-2020, 06:40 AM

Quote:

Originally Posted by bassmadrigal

They can't be a 100% copy because the build systems are VERY different. You have to use a system tool to run PKGBUILDs, where SlackBuilds are simple shell scripts that can be run on any distro (except they'll break due to the lack of makepkg). Much of the PKGBUILD is designed to be used with Arch's built-in tools. You can't "run" a PKGBUILD and get anything even close to building a package. SlackBuilds will do everything on any distro except for the final packaging, but the actual source will be extracted, any patches patched, and the program will be compiled and stored in a folder that could be used for packaging through that distro's tools.

Not literally copies for sure. It's enough to have a quick look at logic of package creation and especially source preparation stage in order to figure out that plenty of SlackBuild scripts are directly mapped from Arch's PKGBUILD scripts. School teachers would not believe in such coincidents.

I.G.O.R · 07-01-2020, 06:46 AM

Quote:

Originally Posted by rkelsen

Have you got any hard data that supports this view?

Perceptions don't require data. I just know how in general people react on the word "Slackware" now, and how it used to be 10-15 years ago.

I.G.O.R · 07-01-2020, 07:13 AM

Quote:

Originally Posted by FlinchX

I'm not an SBo contributor, so I'm in no position to speak for those people, but there's a great deal of effort involved to keep all those SlackBuilds functional and there's an update every week. But as an end user who benefits from it, I find that calling it a "slur" is at least disrespectful. And this is my last post in this thread, because this doesn't seem to be about the future of Slackware, to me it's rather about Slackware not being the way OP wants it to be.

I didn't call it slur. I meant "Go to SBo" as universal answer on everything.

I heard PulseAudio had been on SBo for many years before 14.2. If I would be younger and tried Slackware 5 years ago, I would throw it away immediately after discovering that Slackware doesn't provide PulseAudio and people say me "go to SBo".

I.G.O.R · 07-01-2020, 07:20 AM

Quote:

Originally Posted by kgha

(Ahem) https://www.linuxquestions.org/quest...7/#post5459873

And? It's abandoned.

Some people will say it's not abandoned, it's just perfect and there is no need to improve perfect things.