LinuxQuestions.org
Latest LQ Deal: Complete CCNA, CCNP & Red Hat Certification Training Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 12-24-2017, 09:50 PM   #76
RadicalDreamer
Member
 
Registered: Jul 2016
Location: USA
Distribution: Slackware64-Current
Posts: 847

Rep: Reputation: 391Reputation: 391Reputation: 391Reputation: 391

Quote:
Originally Posted by Darth Vader View Post
Yeah, and @bassmadrigal helped too by insisting for details...



Sure, you are perfectly right.

BUT, one guy cannot spend his entire life saving to buy (already obsolete) computers, and as I seen at least in Eastern Europe, the expectancy is that the particular good bought (even a fridge) will serve for at least 10 times its saving time, 5 times "only" being for those with a "questionable quality".

So, our particular guy, after saving 2 years, expects to buy something which will work for at least 20 years, or for at least 10 years if it is of a known low quality. This is what I call a non-consumerist way of thinking.

Meantime, many things will be imagined by Intel and AMD. And by the Plasma developers, though.
It is possible to pick technology for a desktop that will last 10+ years if you buy a computer at the right time with the new tech that will last. A new graphics card will probably have to be added in between to extend its life if a good processor is picked. The high end and performance i7 cpus will last 10+ unless you want to do 4k gaming (which isn't really possible yet on high quality even with the mighty 1080 ti gtx based on reviews).
 
2 members found this post helpful.
Old 07-04-2018, 09:22 AM   #77
allend
Senior Member
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 4,998

Rep: Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745
Rather than further derail the requests-for-current-14-2-15-0 thread as occurred since the post I am reviving this thread from six months ago, as we have been around this block before.
My points are:
Quote:
The 'pure 64bit' decision was a very good one. It gives you an expandable core. The worst you can have is a Slackware OS that is multilib by default and then having to decide some years into the future that "32bit is a dead end" and you have to strip the 32bit subsystem from the OS.
from this post.
Quote:
The "design" of 64bit Slackware was the result of a discussion between me and Pat and to some extent, the rest of the team. I wanted multilib out of the box, Pat wanted pure 64bit and we ended up in the middle where the 64bit Slackware is "multilib-ready" i.e. it is 64bit out of the box but a multilib sub-system is easily bolted on. Hence the "lib64" directories for instance.
from this post.

I concur that the future of computing in the near future is 64-bit architecture. The base needs to be pure 64-bit.
Quote:
Remember that I created 64bit Slackware. Not Patrick. And when I created it, I edited every single SlackBuild script in the distro, creating them where missing (not every package was created by a .SlackBuild script back then) and made sure that every package would compile (some had not been recompiled for ages, nobodino will sympathize).
At the same time, ensuring that a single .SlackBuild would be able to compile a 32bit package, and a 64bit package, without modification. Thus not doubling Pat's burden by having to maintain two disjunct distros but enable him to build the two (32bit and 64bit) package trees out of one single source tree.
from this post.
This was a massive effort, all the more remarkable for coming from someone lying in a hospital sick bed. The success can be judged from the Bluewhite64 and Slamd64 projects now being defunct.
Personally, I do not want multilib in Slackware64 by default or even in /extra.
Further, my requirement for 32-bit software support in my Slackware64 installs (to support printer hardware), is a personal need that I am willing to maintain manually. My grateful thanks to Alien_Bob for supplying the 32-bit compatibility packages that make this easy for me. Also, my appreciative thanks to the Slackware crew for the design decision that makes this a straightforward process.

Last edited by allend; 07-04-2018 at 09:24 AM.
 
3 members found this post helpful.
Old 07-04-2018, 09:29 AM   #78
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,330

Rep: Reputation: Disabled
I think there is value for a multilib compatible compiler and libc to be in /extra. Its easy to ignore if you don't want it and it will less likely go out of sync with the main tree. In the event that 32-bit entirely dies and there is no more need for 32-bit compatibility it would be easy to remove it along with the already existing kernel configuration, but I have a hard time seeing this happen in the foreseeable future as long as legacy windows games exist that people want to play with wine.

However its not the end of the world if they are or are not added no matter what your opinion is.
 
4 members found this post helpful.
Old 07-04-2018, 09:45 AM   #79
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,718

Original Poster
Rep: Reputation: 717Reputation: 717Reputation: 717Reputation: 717Reputation: 717Reputation: 717Reputation: 717
Quote:
Originally Posted by allend View Post
Rather than further derail the requests-for-current-14-2-15-0 thread as occurred since the post I am reviving this thread from six months ago, as we have been around this block before.
My points are:
thanks for activating the thread and bringing the current back on topic,

this

Quote:
The 'pure 64bit' decision was a very good one. It gives you an expandable core. The worst you can have is a Slackware OS that is multilib by default and then having to decide some years into the future that "32bit is a dead end" and you have to strip the 32bit subsystem from the OS.
is purely nonsense. obviously there is some confusion with a '32bit subsystem', beside the fact that we had already several wasted years and 32 bit software will not disappear so fast.


I put the whole text here

Quote:
Originally Posted by Alien Bob
Perhaps you are looking at this the wrong way.
Slackware is not meant to be a dogma. If it is created as pure 64bit, then no one prevents you from adding multilib, or to create a 32bit LXC container inside, or whatever.
Slackware provides a platform on which you can build. Slackware does not make assumptions about what its users are going to do with it. The 'pure 64bit' decision was a very good one. It gives you an expandable core. The worst you can have is a Slackware OS that is multilib by default and then having to decide some years into the future that "32bit is a dead end" and you have to strip the 32bit subsystem from the OS. That would be a real bummer.
the problem is, that Slackware does not give me what I need to build because it does not ship a multilib compiler!
I need to replace the ultimative core packages of a distribution to have what I need

Last edited by a4z; 07-04-2018 at 09:49 AM.
 
1 members found this post helpful.
Old 07-04-2018, 10:00 AM   #80
allend
Senior Member
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 4,998

Rep: Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745
Both @orbea and @a4z have raised the suggestion of a multilib compiler. This is a nuance that I have not pursued. I am probably set in my ways. I just accept that compiling on my 32-bit system takes longer. If I could compile more quickly on a 64-bit system and transfer to a 32-bit system, then this would be a significant advantage.
 
Old 07-04-2018, 10:04 AM   #81
GazL
Senior Member
 
Registered: May 2008
Posts: 4,754
Blog Entries: 14

Rep: Reputation: Disabled
Quote:
Originally Posted by orbea View Post
I think there is value for a multilib compatible compiler and libc to be in /extra. Its easy to ignore if you don't want it and it will less likely go out of sync with the main tree.
I think that, along with a desire not to have to replace stock packages wherever possible, are the main issues that swing me to the 'it should be included' side of the argument.

Other than that. I don't have much to say on the subject.
 
1 members found this post helpful.
Old 07-04-2018, 10:06 AM   #82
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,330

Rep: Reputation: Disabled
Quote:
Originally Posted by allend View Post
Both @orbea and @a4z have raised the suggestion of a multilib compiler. This is a nuance that I have not pursued. I am probably set in my ways. I just accept that compiling on my 32-bit system takes longer. If I could compile more quickly on a 64-bit system and transfer to a 32-bit system, then this would be a significant advantage.
I'm not sure we understand each other? To be clear, by the multilib ready compiler and libc I mean they are required for building and running 32-bit programs like wine or pcsx2 on a 64-bit system. Of course this is a niche use case and a lot of people certainly don't need it.
 
2 members found this post helpful.
Old 07-04-2018, 10:12 AM   #83
allend
Senior Member
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 4,998

Rep: Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745Reputation: 1745
I suspect that it is my understanding that is at fault here.
 
Old 07-04-2018, 10:50 AM   #84
chrisretusn
Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware
Posts: 823

Rep: Reputation: 299Reputation: 299Reputation: 299
I am perfectly fine with Slackware64 at it is, pure 64-bit. I want it that way. I see no reason to put it in extra, it's available via Alien Bob's multilib repository. Why waste space in extra. That my thought anyway.

I run pure Slackware64 and with multilib on two machines. At the moment I only use one program that requires multilib and that is Steam. If that ever goes 64-bit, I will probably remove multilib. Compile wise, only VirtualBox needs it to compile, but I use the blob, so 32-bit not needed.

All of my machines are now 64-bit. The last 32-bit machine died a few months ago. I still mirror the Slackware-14.2 and Slackware-current trees locally so if needed install to a virtual machine or install on one of my 64-bit machines.

I hope Slackware (32-bit) is around for awhile longer. Most of the distributions that have dropped 32-bit have only done so in name. The 64-bit install is both 32-bit and 64-bit. Leaves out 32-bit machines, but still allows 32-bit programs. Not many distributions can claim pure 64-bit installations. I like that Slackware64 is one of those. Hope it stays that way.
 
2 members found this post helpful.
Old 07-04-2018, 11:07 AM   #85
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,330

Rep: Reputation: Disabled
For the sake of argument, I do not think adding it to /extra is going to make your Slackware64 installs any less pure.

Also to make sure its clear, the reasoning behind adding it to /extra instead of Alien Bob's repo is that the compiler and libc often are not updated at the same time they are in the main tree for current. Its perfectly understandable that Alien Bob doesn't always have time to update them right away, buts its also understandable that when they are not updated right away that makes it harder for people using them to test the new packages in current until later. Of course everyone could build them individually, but that is a lot of wasted effort not to mention its not always trivial.
 
2 members found this post helpful.
Old 07-04-2018, 07:09 PM   #86
jakedp
Member
 
Registered: Oct 2016
Location: Canada
Distribution: Slackware64
Posts: 130

Rep: Reputation: Disabled
32-bit is not going anywhere. It is going to outlast the amount of time it took 16-bit too die in the Windows world. So come back in 10-15 years and this discussion is relevant.
 
2 members found this post helpful.
Old 07-05-2018, 01:08 AM   #87
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 7,225

Rep: Reputation: 5244Reputation: 5244Reputation: 5244Reputation: 5244Reputation: 5244Reputation: 5244Reputation: 5244Reputation: 5244Reputation: 5244Reputation: 5244Reputation: 5244
Quote:
Originally Posted by orbea View Post
the compiler and libc often are not updated at the same time they are in the main tree for current. Its perfectly understandable that Alien Bob doesn't always have time to update them right away, buts its also understandable that when they are not updated right away that makes it harder for people using them to test the new packages in current until later. Of course everyone could build them individually, but that is a lot of wasted effort not to mention its not always trivial.
There's always only one or a few days of delay inbetween Pat's gcc/glibc releases, and my multilib versions, unless I am sick or on holiday.
It is a rare occurrence (if it happens at all) that people need to wait with upgrading their -current because they have to wait for a new glibc_multilib package. The system will keep running even with the "old" glibc. The same is true for gcc_multilib.
 
3 members found this post helpful.
Old 07-05-2018, 01:37 AM   #88
a4z
Senior Member
 
Registered: Feb 2009
Posts: 1,718

Original Poster
Rep: Reputation: 717Reputation: 717Reputation: 717Reputation: 717Reputation: 717Reputation: 717Reputation: 717
Quote:
Originally Posted by Alien Bob View Post
There's always only one or a few days of delay inbetween Pat's gcc/glibc releases, and my multilib versions, unless I am sick or on holiday.
It is a rare occurrence (if it happens at all) that people need to wait with upgrading their -current because they have to wait for a new glibc_multilib package. The system will keep running even with the "old" glibc. The same is true for gcc_multilib.
and this is why something essential like glibc and gcc have to be part of the distribution and arguing around does not change this fact.
we are not talking about some media player but essential key components of a distribution that Slackware refuses to deliver, for reasons I can only speculate about, but for sure non of the expatiation I can thing about have anything to do with anything of the interpretations some people here invent.
 
1 members found this post helpful.
Old 07-05-2018, 01:41 AM   #89
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,330

Rep: Reputation: Disabled
Quote:
Originally Posted by Alien Bob View Post
There's always only one or a few days of delay inbetween Pat's gcc/glibc releases, and my multilib versions, unless I am sick or on holiday.
It is a rare occurrence (if it happens at all) that people need to wait with upgrading their -current because they have to wait for a new glibc_multilib package. The system will keep running even with the "old" glibc. The same is true for gcc_multilib.
Yes, I was not clear enough. I meant testing the new versions of glibc/gcc, either of which could cause regressions in programs I or someone else builds individually. For example I recall when gcc 7 was added to current I found that the rendering in pcsx2 broke entirely, after countless tedious recompiles the issue was narrowed down and a pcsx2 developer reported a small test case to gcc upstream who then fixed it promptly and Pat then applied the upstream fix to Slackware.

Usually you are pretty fast about updating them and its not an issue, but nevertheless real life happens and its hard to predict the future.
 
1 members found this post helpful.
Old 07-05-2018, 01:53 AM   #90
RadicalDreamer
Member
 
Registered: Jul 2016
Location: USA
Distribution: Slackware64-Current
Posts: 847

Rep: Reputation: 391Reputation: 391Reputation: 391Reputation: 391
I think multilib in Current comes out promptly. If multilib was in extra it would be easier for people to get it who need it. I think the biggest reason for multilib to be moved to extra would be all the public mirrors for it.

What I think needs to be done is for the Slackware webpage to be updated so people can learn how to easily add Alien Bob's multilib to their system if they need it. That webpage needs to be updated before Slackware 15 is released! I think multilib is a non-issue as long as Alien Bob or someone part of the Slackware team produces packages for it. I'm going to be needing it for years to come. Its going to be relevant as long as we have computers with x86_64 processors.
 
3 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Ubuntu 32-bit Future? wagscat123 Ubuntu 3 11-03-2016 10:18 AM
LXer: GNU/Hurd Plans For A Future With USB, SATA, 64-Bit LXer Syndicated Linux News 0 02-10-2013 04:01 AM
How important is 64-bit support in future Slackware? wheeliee Slackware 36 03-25-2009 05:34 AM
LXer: Desktop FreeBSD: 64-bit Future LXer Syndicated Linux News 1 10-06-2006 11:14 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 07:55 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration