Understand Puppy T2 development environment

[Lobster]

Sage has asked me to explain T2
- I'll try . . . this is what I think it is . . .

When Puppy started the kernel and files came from and were compiled in Red Hat , then Mandrake, then Vector Linux.

Now Puppy C and C++ source code can be optimised for and compiled in Puppy. We are bootstrapped.

T2 is a system of ordering and structuring the compiling of a distro.
If libraries or dependencies (like dll files in Windows) are required the T2 lets you know what you have and what is needed. So reliability is increased and duplication avoided. The internal structure of Puppy will be simpler. As Barry mentions in the following post - End Users will not notice any differences.

Programs that were used from other distros will now be compiled by for in and with Puppy.

People wishing to have a specific arrangement of programs may find (if sufficient interested Puppys set up T2 systems) they can be offered a streamlined Modular Puppy that works as soon as created.

Because compilers become available for other processors, we could run Puppy on a cell processor or other evolving specialised chips. Puppy would be cutting edge. Being tiny we could have a working distro on a new processor in a few days of the released compiler.

For Puppy developers the T2 system means code can be tried out and compiled. Barry can make available components of Puppy - so we can in theory have nightly builds of the distro (that may be dependent on a very fast processor or grid array and Broadband)

It means other things. Security problem? Puppy is on it. Bug. It can be addressed and the component sorted and available.

Barry is working on a version of T2 for Puppy. It will be smaller - tailored to Puppy needs.

It may just mean that ordinary Puppys will be finding C code - compiling it and making it available . . .

Sounds like fun already . . .

[BarryK]

We can compile Puppy totally from sources, including kernel, x11, gtk.
Potentially for other CPUs one day, not just x86.

We will still have the same Puppy from the end-user viewpoint, T2 is only
an issue for the "core developers". Even most "application developers"
won't be effected, they just carry on as normal.
To emphasise: THIS IS A NON-ISSUE from the end-user viewpoint,
Puppy will be the same as before.

Advantages? For a start, compiling everything from source means maximum
compatibility. Secondly, it is easier to upgrade, say we want to go from GTK
2.8 to 2.10. Thirdly, it provides a common framework for the core developers
to cooperate and synchronise their work. Fourthly, we will have a formal
technique for creating our "devx" module, which is currently an ad-hoc manual hack.

I must emphasise though, I'm evaluating T2, haven't chosen it.
Right now, there's some packages that won't compile. If I get that sorted out,
then it will be looking real good, and I'll write-up a web page that introduces
"T2P" (T2-Puppy) and explains how to use it.

[Sage]

Thanks, guys. I guess it's 'compiling' that I have never understood - and still don't. Used to do some minor assembly stuff in 8-bit twenty years ago, parrot fashion, and was aware that our Ferranti 1904 needed to do this compiling thing forty years ago. Once knew a guy who could program a PDP11e in binary using the switch bank! Also had several skirmishes with FORTRAN & BASIC. Compiling remains a massive hole in my understanding/brain. End of story.

[willhunt]

so does this mean that instead of iso files of various builds that one would
be able to just download a bash script and shazam your own custom
puppy iso?

[John Doe]

Something like that.

In fact "Puppy Unleashed" comes pretty close. If you haven't checked it out, I would recommend doing so. I'm kicking myself in the behind for not trying it sooner.

[MU]

compiling...

you can write programs in assembler, which is almost "perfect" in the eyes of a computer, very close to binary code.

lda 02 -- load stack with value "2"
sta #c000 -- save stack in byte 49512 of the memory
lda #c001 -- load stack with value from byte 49513
cmp #c000 -- compare value in stack with value from byte 49512
bne d000 -- branch if not equal to a subprogram beginning in byte 52148

The part after the "--" is just comment, not part of the code.
Might be erratic as I did such stuff 20 years ago, and forgot most, but it illustrates (macro-)assembler.

But this is difficult to understand, in C it might look like this:
a=2;
b=c;
if (a != b){
my_subroutine();
}

This is easier to understand (high-level language), a simple comparison of two numbers, and depending on the result (if they are different), a sub-program is executed.

As computers do not understand "if" and don't have variables (C) but only a stack (assembler), the code must be translated from C to assembler or even better directly to binary code (assembler itself is not binary, but a very simple form of a "high-level-language" very close to binary code).

This translation is "compiling".
If you open the resulting "code" in a hexeditor, you will only see binary code, values from 0 to 255 "wildly mixed". The computer can understand this code, but no human can.

Mark

[Lobster]

I have put Marks info here

http://puppylinux.org/wikka/Compiling

. . . that page needs compiling (another use of the word but related)

[Sage]

Ah ha! That certainly fills a gap - many thanks for taking the trouble, guys - much appreciated. However, as a scientist, I would find binary and assembler more intuitive! They are simply versions of arithmetic and algebra, respectively and relate to real, tangible physical operations like loading and moving values into and out of registers, incrementing and decrementing, etc. Using high level laguages has always confused me and begs the question - why?! Surely it must be extremely inefficient? What extra overheads and restrictions are incurred? So, is T2 some piece of software that translates from high level to low level? Then what? Assembler down to binary? How is this accomplished? Why don't folk still use assembler? It didn't seem a problem forty years ago, even for teenies. Presumably serious hackers still prefer the 'direct' approach? Lots more questions, but, not being a mathematician nor IT person, I may find it difficult to ask intelligent questions and understand the answers!
Communicating across the sciences, never mind real life, is supposed to be the measure of a successful academician. Most correspondents in this Forum surpass expectations in stark contrast to the norm in this field!

[MU]

I know nothing about T2, except what I've read from Barry.
According to that, it is simply "compiling", but with an additional dependency-manager.

So you will not have the trouble of searching 1000 websites for required libs for your program, just to find out, that it conflicts with the program you compiled just a day ago.

Assembler is very effective, it was 200 times faster than basic on the C64, but only 3-6 times faster than C.
Object-orientation in assembler might be almost impossible, so you would have no frameworks like Gtk or Qt in assembler.
It is good to use for extremly timecritical operations using only integer-arithmetik, like blitting bits in video-memory (drawing lines and such).
As every computer-architecture is very different in memory-management, assemblercode is not portable (as it adresses the memory directly), so you can design programs only for i386 OR power-pc, different to code in C or even "higher" languages like basic (script-languages).

Mark

[pakt]

Why don't folk still use assembler? It didn't seem a problem forty years ago, even for teenies.

Sage, in a nutshell it's ease and productivity vs efficiency, size and speed.

Assembler is still often used in microcontrollers where cpu power and memory size is limited. But even there, the high level language 'C' is becoming more usual.

[Sage]

Ah, yes, but! If assembler is speedy, compact and efficient, wouldn't it still be the optimum choice, presuming that coders were coached in its use? In the aulde dayes perhaps the easy choice wasn't available? We are awash with inefficient coding, bloat, Easter Eggs, huge reservoirs of redundant code, etc., all requiring HW way beyond reason and rationality - or maybe those criticisms only refer to our favourite punch bag?!

[pakt]

Ah, yes, but! If assembler is speedy, compact and efficient, wouldn't it still be the optimum choice, presuming that coders were coached in its use?

Yes, but optimum for whom? Corporations aren't interested in 'speedy, compact and efficient' code when a program can be written in less than 1/10th the time in a high level language. Competition and profit I would think are the driving forces.

Now if the program was a labour of love...

[Sage]

Good point, except perhaps intrinsic efficiency saves everyone more dosh in the longer term and reflects on greater profits. So far, the IT game has been a constant escalation of HW vs. SW played out between two greedy companies who have got away with supplying defective products. The cost and wastage amongst poorly informed consumers has been staggering. The cost to the planet may prove unrecoverable. I still hear the echo about Apollo getting to the moon in 2K of memory. My 128K 8-bit machine could handle DTP GUI with a mouse and resources to spare. The IT biz has moved to essentially male domination, so the go-faster stripes and testosterone excesses have dominated extremely successful marketing operations. Time to call a halt. Good education strategies must prevail and that surely should include well-taught programming? Puppy, inter alia, offers great promise for a more rational approach? Trouble is, I find it difficult to understand the nuances like T2!

[pakt]

Good point, except perhaps intrinsic efficiency saves everyone more dosh in the longer term and reflects on greater profits. So far, the IT game has been a constant escalation of HW vs. SW played out between two greedy companies who have got away with supplying defective products. The cost and wastage amongst poorly informed consumers has been staggering. The cost to the planet may prove unrecoverable. I still hear the echo about Apollo getting to the moon in 2K of memory. My 128K 8-bit machine could handle DTP GUI with a mouse and resources to spare. The IT biz has moved to essentially male domination, so the go-faster stripes and testosterone excesses have dominated extremely successful marketing operations.

Yes, sad isn't it?

Time to call a halt. Good education strategies must prevail and that surely should include well-taught programming?

A nice utopian view. Unfortunately, the 'halt' will only come when we are forced to a halt by circumstances beyond our control and not by choice.

Puppy, inter alia, offers great promise for a more rational approach?

Yes, there are a few of us that are wise enough to take this path, but how do you convert the masses? Education requires effort...

Trouble is, I find it difficult to understand the nuances like T2!

That was an elegant transition back to T2

[Sage]

Tack so mycket, pakt! Just one last question, as the season for maturity approaches, where in the UK can I buy sorstromming?!!

[pakt]

Tack so mycket, pakt! Just one last question, as the season for maturity approaches, where in the UK can I buy sorstromming?!!

Pretty good Swedish, Sage! I've only eaten surstr

[PaulBx1]

Sounds like something a Swede would eat (my Norwegian part is snickering).

Sage, I can empathize. I have done a lot of assembly coding of Data General Novas, PDP11's, 2901 bit-slice machines and highly parallelized and pipelined array processors (with the latter you could write a 1-instruction loop that did something actually useful ). An amazing amount of stuff could be done with such coding and small memories; and what's more, I thought it was fun!

However, that's not the way of the world. C is just more general and portable and more people know it. The infrastructure for it is out there. Face it, we are dinosaurs.

What I have problems with is C++; never figured out the point of it (seems like C could always do about the same thing, while being more intuitive besides).

However we are getting off-topic. T2 sounds worth investigating, and a large time-saver over the long run. From what little I understand of it.

[willhunt]

has got me wondering what happened to menute or M078 I started to play with it and went to goosee and found puppy when I went to check on it just now it seems to be gone.............not forever I hope anyone know if BK intends to do
with it now?

[BarryK]

I was only a contributor to the Menuet OS.
I think the original developer left, but it is still continuing ...somewhere.

[PaulBx1]

There is this warning on the Enigmail site:

Enigmail needs to be compiled using the same environment as the Thunderbird or Mozilla Suite you are about to install it on. This usually means that you should either use the official binary builds of both (the Mozilla application and Enigmail) - or only use packages provided by your distribution - or build both manually. For example if you use a distribution Thunderbird package with the official Enigmail build, you will encounter problems!

http://enigmail.mozdev.org/download.html

I did try to build Enigmail but got nowhere, probably because I didn't have the SeaMonkey build environment. Is this T2 stuff going to help with that?

I can see (with my limited understanding of this) two possible ways to go. 1) Get a Seamonkey Puppy ISO, with (one hopes) the compile environment included so I can reuse that when building enigmail; or 2) get a barebones Puppy and build both Seamonkey and Enigmail into it. This would mean I'd need also to build or at least install the other things I use in a SeaMonkey Puppy, such as gnumeric. I'm guessing that is just a pupget...

Does this make sense?