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???

If Slackware64 is multilib;

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.

The other side of the coin could be:

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

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 !

Hi,
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.

Reading the response to samac's post...
 

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...

Shingoshi

Hi,
Probably only you.

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.

Highlander: There can only be one...
 

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.

Shingoshi

Hi,

Do you really understand the word 'port'?

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.

Onebuck

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

Hi,
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!

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.

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.

Hi,
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.

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.

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. :)

Hi,

I thought you were speaking about the hardware thus the architecture. As I stated the world still has a need for that style of hardware.

benjo316,
Just out of curiosity, would you look and see what processor the system uses. NetBSD supports some very old equipment and would likely have the drivers to load for it. It would just be real crazy to install NetBSD and then compile a linux system on it if possible. At least, it would bring a big smile to your face if you succeed.

Shingoshi