Slackware64 -current vs Slackware -current or Slackware
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Slackware64 -current vs Slackware -current or Slackware
Hi,
I've noticed a trend here on Slackware LQ concerning the difference that some members feel exists between the architectures -current. Or what will exist when the team releases stable. The OS will be the same since x64 was done in sync with x86. The installation choice will be up to the user to select as long as the user has the supporting hardware.
Now, will you be able to utilize the wonderful 32bit app that you cannot live without on the x64???
Mon May 25 17:52:56 CDT 2009
a/cryptsetup-1.0.6-x86_64-1.txz: Upgraded to cryptsetup-1.0.6.
d/binutils-2.18.50.0.9-x86_64-2.txz: Changes to enable multilib support.
Thanks to Fred Emmott.
d/gcc-4.3.3-x86_64-4.txz: Changes in specs file to enable multilib support.
Thanks to Fred Emmott.
d/gcc-g++-4.3.3-x86_64-4.txz: Recompiled.
d/gcc-gfortran-4.3.3-x86_64-4.txz: Recompiled.
d/gcc-gnat-4.3.3-x86_64-4.txz: Recompiled.
d/gcc-java-4.3.3-x86_64-4.txz: Recompiled.
d/gcc-objc-4.3.3-x86_64-4.txz: Recompiled.
xap/MPlayer-r29322-x86_64-1.txz: Upgraded to revision r29322.
isolinux/initrd.img: Rebuilt.
usb-and-pxe-installers/usbboot.img: Rebuilt.
of course you can use the 32 bit app with your x64 if indeed the multilib is there.
Then why not just use Slackware x86 instead of Slackware64?
My personal opinion is that there are and will be more x86 systems available than x64 for users to have Slackware available to them for use. The argument that x64 is powerful enough to use both. Well yes and no! First to use a 32 bit app in a multilib system will give up something on a x64. The use will give up efficiency for convience. Sure that can of worms will be argued but it's true. Tick ..Tick ...Tick...
I'm a person who feels that the tool should fit the usage. You don't use a screwdriver as a chisel. Some think it's OK but it is dangerous to misuse. I feel the same with any OS. Again that's another argument for some to debate later.
Slackware64 or Slackware? They are the same! Choose your fruit to suit your salad.
Just remember that 32bit apps will take some time to catch up to 64bit. That is if the said app even makes it to 64bit. The other argument is that when will the number of 64bit machines worldwide catch up to the number of x86 machines available in the world for users to have Slackware?
Not everyone has the means to update to the most current hardware to use the most current software!
Note: Neither this post nor I (onebuck) officially represent SlackwareŽ in any way.
Last edited by onebuck; 06-10-2009 at 04:41 PM.
Reason: add note
That the user has a 64 bit computer and wishes to make full use of the hardware. They also have a single 32bit program that they wish to use. Now do you run all 32bit because of one program, or with compatibility libraries, or install two systems on the one computer so that you can chroot, or just run two computers.
None of the above are perfect. However some are more perfect than others. The one that is most perfect is the one that is most convenient to the user.
Distribution: slackware64 13.37 and -current, Dragonfly BSD
Posts: 1,810
Rep:
All interesting points .. I get the distinct impression that a lot more people - perhaps newcomers - are interested in running Slackware64 -current than would be running plain -current. Maybe because it's 64bit and people assume a performance enhancement.
I can see the convenience in addressing fully and properly a large memory configuration without needing a kernel recompile and using PAE. Personally I think, (and have found by my own experiences), that that's where the advantages end. The majority of applications won't be noticeably quicker on a true 64bit architecture. Particularly in the desktop arena.
OK - certain applications like video transcoding and such may be speeded up but the majority of things - ( net related ) - are obviously limited more by network speeds than anything else.
Also - Slackware64 -current doesn't post the CURRENT.WARNING that standard current carries. Not sure if this is a bad idea or not.
Don't get me wrong - I think the production of a 64 bit version of Slackware is to be applauded and the team are to be praised. I just feel that people may be foolishly looking for a non existent benefit.
Anyway - just my cynical two pence worth ! There have already been to many arguments on these subjects and it's not even released yet !
That the user has a 64 bit computer and wishes to make full use of the hardware. They also have a single 32bit program that they wish to use. Now do you run all 32bit because of one program, or with compatibility libraries, or install two systems on the one computer so that you can chroot, or just run two computers.
None of the above are perfect. However some are more perfect than others. The one that is most perfect is the one that is most convenient to the user.
samac
I understand your point and position. But for Slackware to benefit everyone (worldwide) then the availability should be as the team has specified. That way the user base will be broader but the specialized user CAN setup according to their needs. As everyone knows that's the Slackware way! It is not fair reasoning to restrict a user for another user's need. That's why there will be Slackware and Slackware64 when released stable.
Slackware64 will have multilib so I see no reason to complain about not having the ability to run a 32bit app except that the performance of the app and that the app may fail. As for something like emulation you may experience some issues but those too will be corrected or possibly other avenues can be used(VM anyone).
One person's convenience may be someone Else's inconvenience or vice verse. I'm not being smart here either, it's just that this is Slackware GNU/Linux not M$. I really believe it is wise to release Slackware the way 'PV' seems to be going.
Note: Neither this post nor I (onebuck) officially represent SlackwareŽ in any way.
That the user has a 64 bit computer and wishes to make full use of the hardware. They also have a single 32bit program that they wish to use. Now do you run all 32bit because of one program, or with compatibility libraries, or install two systems on the one computer so that you can chroot, or just run two computers.
None of the above are perfect. However some are more perfect than others. The one that is most perfect is the one that is most convenient to the user.
samac
I wonder how many think there is only one definition of a Slackware user? And anyone who functions outside of that definition, isn't a genuine Slackware user. Just wondering...
I wonder how many think there is only one definition of a Slackware user? And anyone who functions outside of that definition, isn't a genuine Slackware user. Just wondering...
Welll, ... heh heh, every once in a while and particularly for the really thin, fine work. But then I guess we could just temporarily rename it a chisel.
The notion that there will be more than one version of Slackware is incorrect, if you accept that Alien Bob should know what he's talking about.
Quote:
Originally Posted by Alien Bob
It is still called Slackware. The directory with the 64bit port is called slackware64-current but the official name for the distribution is "Slackware for x86_64" - see the ChangeLog here: http://www.slackware.com/changelog/c...php?cpu=x86_64
There will not be a "default" Slackware. There will be a release for each of two architectures (x86 and x86_64) and these are being maintained in sync. You get to choose what you want to install.
Do not think that x86_64 will be the predominant platform any time soon... the largest growth in computer sales this past year is in the netbook area, and those netbooks are all based on 32bit CPU's (mostly Atom270).
I never mentioned separate releases but when the 'Slackware64 -current' is finished along with Slackware stable. The user will have the option to choose for his/her architecture. We are talking plural here when you have something running in sync during the '-current' development. No one is speaking about separate except you. When we speak we should define the x86 & x86_64. If somebody did not understand my meaning in the OP then my apologies but the educated do know that 'Slackware -current' is 32 bit (x86) and that 'Slackware64 -current' is 64 bit (x86_64).
BTW, grow up! I've looked at some of your posts and really think you need to do something to aid yourself with the problems.
I wasn't actually complaining, all I did was to highlight an alternate opinion. I have absolutely no "beef" with the way that Slackware is being developed or released, I just wished to point out that people have choice to choose "convenience over efficiency".
I wasn't actually complaining, all I did was to highlight an alternate opinion. I have absolutely no "beef" with the way that Slackware is being developed or released, I just wished to point out that people have choice to choose "convenience over efficiency".
samac
I didn't take it as a complaint. That's what's great about Slackware. We do have choices as to how we want to configure our systems. Each to his own!
Then why not just use Slackware x86 instead of Slackware64?
It, of course, depends on your specific needs. Some will only be able to use 32 bit Slackware. Others will be able to use either, and can decide based on fact, superstition, or whatever other way they might devise. I use 64 bit software because it's a "more recent" architecture, but that's not really important.
Quote:
Originally Posted by onebuck
You don't use a screwdriver as a chisel. Some think it's OK but it is dangerous to misuse.
Some people do use a screwdriver as a chisel... "Should not" would be more appropriate here, I believe. And I think it's less dangerous, in this case, than it is inefficient (and possibly damaging) to the screwdriver. You could say the same thing about using 32 bit software on a 64 bit OS; It may be inefficient (and possibly, but much less likely, damaging), but sometimes it's something you have to do.
And sooner or later, the 32 bit x86 architecture will become obsolete, and something better than the current x86_64 architecture will be made. It may not be another change in the number of bits, but it will happen. And people will probably still use the old hardware, but lack of compatibility with "current" hardware will inevitability make "old" hardware sparse.
R we still talking about screwdrivers? Let's just say you don't use a phillips screwdriver as a chisel (except for those nice pointy indents). I would have said that earlier but I couldn't remember if phillips had one L or two. Still don't remember.
Now I'm going to have a screwdriver (vodka and orange juice) which is nearby on my horizontal tower 16-bit PC which I use as a coffee table. Just joking. All of you, I don't care what you call your tools, but get back to work.
It, of course, depends on your specific needs. Some will only be able to use 32 bit Slackware. Others will be able to use either, and can decide based on fact, superstition, or whatever other way they might devise. I use 64 bit software because it's a "more recent" architecture, but that's not really important.
The availability is important. Not everyone in the world has the newest architecture but still rely on a basic x86 machine. The numbers are there to show the need for support of the older architecture.
Quote:
Originally Posted by benjo316
Some people do use a screwdriver as a chisel... "Should not" would be more appropriate here, I believe. And I think it's less dangerous, in this case, than it is inefficient (and possibly damaging) to the screwdriver. You could say the same thing about using 32 bit software on a 64 bit OS; It may be inefficient (and possibly, but much less likely, damaging), but sometimes it's something you have to do.
The possible damage to the person(s) is what I was stating when something is misused or not used as it was designed. As for the 32 vs 64 applications it may be the only outlet to attempt to use a 32 on a 64 but not a restricting case. If you really need the application then it would be better to utilize a 'VM' to provide a stable means of running the 32bit app on the 64 machine without the worry of lib mixing.
Quote:
Originally Posted by benjo316
And sooner or later, the 32 bit x86 architecture will become obsolete, and something better than the current x86_64 architecture will be made. It may not be another change in the number of bits, but it will happen. And people will probably still use the old hardware, but lack of compatibility with "current" hardware will inevitability make "old" hardware sparse.
I really don't see that happening. The 32bit machine will not expire as fast as it's predecessors. Heck, netbooks and some laptops are being built with the 32bit for power reasons. Until the battery design is improved the 32bit low power processors will be around.
Another point is the number of 32bit machines still in operation let alone the lowly 486 (bit gods please forgive me). I think you should look at the world instead of places like here that can afford the upgrade to the latest and greatest.
The sparsity of a base of hardware that is functional will someday evolve but it will be due to the replacement parts to keep things going. We've got a place in town that gets old laptops from around the world. They strip them for parts to resale. Growth has been phenomenal! These re-distributors are in great demand and are always seeking new sources of old equipment. The demands are there. The modern day junk yard.
For clarification, I didn't mean 32 bits would be out the window soon (or eventually), but that the current architecture (ie: i686, or whatever). One could also argue that ARM is becoming popular, but I won't because I have no idea.
And sorry about bringing the screwdriver back... I just couldn't resist.
Edit: For extra, extra clarification: I meant really old hardware. Obviously, an i386 computer will still be compatible with an i686 computer, or Power, or ARM, etc.. But when a computer no longer has software developed for it, or the network hardware is no longer made, it gets more and more difficult to use with new hardware and software. For example, I have an old computer below my desk which I don't even know what processor it has in it. It had Windows 3.1 installed when I got it. I can't install a new OS because it doesn't boot from CD-ROM and the CD-ROM drive isn't visible after booting from a floppy. That's what I meant.
Last edited by benjo316; 06-23-2009 at 11:44 AM.
Reason: brought the 'ing' to bring, because I brought it back with that last post.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.