...and today is 23-05-2022 at 16:52:28 (Cordoba, Cordoba, Argentina timezone), at least according to the Motorola G5 Plus running LineageOS 17.x (rom downloaded from the XDA Forum).

<off-topic>I've written something, however it is in spanish.

I don't know if I'm going to translate it to english before June 28th.

My facebook username is fourteeneightythree if you want to check the spanish version of the last FB post on my profile.</off-topic>

On-topic:

Would the Slackware team and its users want to help me translate all of the latest release of Slackware 64 sourcecode to Assembler?

Or maybe we should port the i386 version of the sourcecode and then build the 64 bit Assembler from there?

Kind regards.


Maybe this would be the new 1337 (shall we call it 1338?)

As I said on this thread's title I'd join the project on July 1st.

Welcome to this forum.

Good idea! Just do it and come back when ready so we can try it.

All of it? Including things like KDE, or are you referring to just the base Slackware source?

1 members found this post helpful.

I fixed that for you.

As the project originator it is up to you to initiate the project and invite others to join, not the other way around!

1 members found this post helpful.

All of it . The kernel, the userland, the complete lastest stable release of Slackware.

April Fool's day was more than 8 weeks ago.

5 members found this post helpful.

To what possible purpose?

1 members found this post helpful.

Reutilization of old hardware with the best GNU/Linux Distribution.

You're actually serious??

Ummm... Not to rain on your parade, but the Slackware source tree is 6.2Gb... compressed.

But don't let me stop you.

2 members found this post helpful.

Pretty sure if you want this, you'll be the only one working on it.

The benefit to effort ratio is EXTREMELY lopsided.

2 members found this post helpful.

Somewhere over the years I was given to understand that a high quality compiler will produce optimized machine code which will rival that produced from the assembly language code written by a very good programmer.

The problem with assembly language is: relatively few people are able to do a good job writing in it, and/or in modifying existing code. Whereas most humans find it much easier to work in the high level programming languages, than with assembly language.

Even if a crack-team of programmers quickly rewrites the entirety of the existing version of Slackware into assembly language --> who on earth is going to maintain it for the next 5 or 10 years?

The biggest question is: has the Slackware Team the intention and the human and logistic resources to fork the entire open source, Linux and GNU ecosystem and Slackware Linux to become an unique Slackware OS? Most certainly NOT.

And I remember that at a Linux conference in AD 2019 a speaker said that a single programmer needs 20 years ONLY to read carefully the Linux kernel source code. This big was 3 years ago the work of Mr. Torvalds. Probably now it's even bigger. And this is only the kernel.

Probably there are needed hundred of thousands of fine assembler programmers to rewrite in reasonable time (10 years?) a modern Linux distribution in assembler language.

Did you people can imagine the logistics of maintaining a project with hundred of thousands programmers working full time? And who will pay them? The Slackware, Inc. ?

Heck, let's make a distinction between reality and science-fiction!

Great idea!!! But why not go even crazier and "translate" it all to binary?
Get one of these:
https://stock.adobe.com/images/three...ayout/60249899

1 members found this post helpful.

I think I am correct in saying that different CPU architectures use different assembly language system calls.
e.g in 64 bit Linux to use SYSCALL, first put the system call number in RAX, then the arguments, if any, in RDI, RSI, RDX, R10, R8, and R9, respectively, whereas in 32 bit Linux it's EAX for the call number and EBX, ECX, EDX, EDI, and ESI for the arguments...

To rewrite the whole of Slackware would get very complicated very quickly.

If you really are that eager to port any code to assembly language, why not start with something simple, say the echo command, to get a feel for it?
Then select something just a little bit bigger and try that? And so on?

I'm sure that, at some point, you'll find that it becomes far too much effort, and it will take far too long, to ever get a significant portion of such a massive collection of codebases done. Still, if you really make a serious effort at trying the simple stuff first, I'm sure you will become quite good at programming in assembly language, and at debugging!

1 members found this post helpful.