DSL Editions
Forum: Other Help Topics
Topic: DSL Editions
started by: cmanb
Posted by cmanb on June 17 2008,04:04
I'm positive that this must have been covered elsewhere, but it seems to me that DSL is factioning and branching out into several editions.I know what DSL-N is. But what is this much-rumored "small core" version of DSL about? I'm assuming a stripped down, no-X version? That sounds cool.
But what is the ultimate aim of having two versions of DSL, the 3.x and the 4.x?
We (soon will) have three different "editions" of DSL now, the main one coming in two flavors. You have to pick one of those before you can even start thinking about frugal, poorman's, HD-install, live-CD, or embedded.
That seems a bit overwhelming to me, and I've been following this distribution for years. God save the newcomers.
I'm hoping, I guess, that somebody will write up a "Which DSL is right for me?" primer and post it somewhere.
Posted by Jason W on June 17 2008,04:31
From what I understand DSL-N is no longer going to be developed. Same as DSL version 3.x. What is being developed and supported is DSL version 4.x and the upcoming tiny core. So 2 versions are going to be active. One for the 2.4 kernel with a functional desktop (what we know today) and the 2.6 kernel tiny core, which will rely on MyDSL extensions for the packages that make the system what you want/need it to be. DSL "classic" is for older hardware (and most newer except for exotic peripherals) and existing MyDSL extensions. Tiny core will be for newer hardware (as well as most existing), with the 2.6 kernel and a smaller, more up to date core system.That is it I guess in a nutshell. Anyone who knows more please elaborate.
Posted by ^thehatsrule^ on June 17 2008,04:32
| Quote |
| But what is this much-rumored "small core" version of DSL about? I'm assuming a stripped down, no-X version? That sounds cool. |
| Quote |
| But what is the ultimate aim of having two versions of DSL, the 3.x and the 4.x? |
| Quote |
| You have to pick one of those before you can even start thinking about frugal, poorman's, HD-install, live-CD, or embedded. |
| Quote |
| From what I understand DSL-N is no longer going to be developed. Same as DSL version 3.x. What is being developed and supported is DSL version 4.x and the upcoming tiny core. So 2 versions are going to be active. One for the 2.4 kernel with a functional desktop (what we know today) and the 2.6 kernel tiny core, which will rely on MyDSL extensions for the packages that make the system what you want/need it to be. DSL "classic" is for older hardware (and most newer except for exotic peripherals) and existing MyDSL extensions. Tiny core will be for newer hardware, with the 2.6 kernel and a smaller, more up to date core system. That is it I guess in a nutshell. Anyone who knows more please elaborate. |
Posted by roberts on June 17 2008,04:43
From the main DSL web page:| Quote |
| 3.x Supports Application launching from limited icons. Application centric. Menu driven. Current 3.x version 3.4.11 4.x Supports Drag-N-Drop, Folder/Document centric. Many icons. Can be run menuless. Current 4.x version: 4.4 |
In addition 3.x is kernel 2.4.26 with many scsi modules. It is frozen with no futher updates planned.
4.x is kernel 2.4.31 with some SATA boot time support with less scsi modules and with many apps updated including core lua/fltk as used by the mydsl extension system. This is still being updated and maintained.
Tiny core is a much asked for stripped down version of DSL with 2.6.24 kernel + a very extensive build of busybox + lua + fltk + murgaLua bindings + jwm. It boots into tinyX server either Xvesa or Xfbdev + jwm (might switch to flwm to reach an 8MB size) It can run only fltk or lua/fltk programs. But this means it can support the MyDSL extension system.
No installation scripts, limited modules, boots entirely into ram. iso size is currently 9MB. One can mydsl-load gtk1.dsl and use some of the gtk1 apps from current DSL. Basically everything is an extension for tiny core. I will post as soon as I can contact John.
So, in conclusion, the next version/edition of DSL will be more open to community involvement via the extension system. While at the same time be moving to support a much smaller desktop based on fltk apps and/or lua/fltk apps. Hopefully since the community has asked for this, that a solid gtk2 extension and gtk2 apps will emerge.
Posted by chaostic on June 17 2008,07:36
How much of the 9mb's are jwm and jwm only dependancies? Some of us still prefer fluxbox (which should be loaded via the repository)...
Posted by curaga on June 17 2008,08:47
Since jwm only depends on X libs and image ones, the same as Fluxbox, I don't think there's anything more than jwm itself.
Posted by clivesay on June 17 2008,11:41
Can't wait to try it, RS!
Posted by lucky13 on June 17 2008,12:41
Re 3.x, 4.x, etc...Many distros continue to support older versions. Slackware 8 is still supported even though they're now at 12.1! Debian still has repos for Sarge online. Etc. So DSL's overlapping support for 3.x/4.x and now 4.x/TinyCore is hardly novel or confusing if you're used to any other distro. Or even OS since Microsoft supports releases even after new ones come out (such as still supporting XP for however much longer even though Vista is out).
DSL's earlier versions are still available and should continue to remain available for those who have older hardware or who, for whatever reason, are enamored with a particular version number. It's already been explained why the "benefits" of 3.x make it desirable for certain users, and dittos for 4.x. I don't think it's too confusing is people read the documentation and figure out what their hardware needs are.
Posted by lucky13 on June 17 2008,12:58
| Quote |
| How much of the 9mb's are jwm... |
My largest stripped jwm binary is 168kb, with every option compiled in. JWM doesn't have any peculiar dependencies.
See (note: this wm memory use comparison has been updated!):
< http://gilesorr.com/wm/memory.html >
Posted by cmanb on June 17 2008,19:36
| Quote (roberts @ June 17 2008,01:43) |
| So, in conclusion, the next version/edition of DSL will be more open to community involvement via the extension system. |
Do you mean in the sense that users will need to create/use extensions to enhance functionality?
As opposed to just "breaking" the system and using apt-get just because it's initially more familiar?
Posted by clivesay on June 17 2008,19:46
| Quote (cmanb @ June 17 2008,18:36) |
| Do you mean in the sense that users will need to create/use extensions to enhance functionality? |
Absolutely.
Tiny Core will basically be a base to build the OS of your liking. You will either need to understand how to build extensions or will have to be patient and hope someone builds something you want to have. It's not going to be for the new Linux user. My hope (and I know Robert's) is that this core will inspire the community to build extensions to make tiny core a very flexible system.
Personally, I can't wait.
Chris
Posted by cmanb on June 17 2008,20:16
| Quote (clivesay @ June 17 2008,16:46) | ||
Absolutely. Tiny Core will basically be a base to build the OS of your liking. You will either need to understand how to build extensions or will have to be patient and hope someone builds something you want to have. It's not going to be for the new Linux user. My hope (and I know Robert's) is that this core will inspire the community to build extensions to make tiny core a very flexible system. Personally, I can't wait. Chris |
But the extensions that currently exist will work with Tinycore, right?
I guess what will need to happen is people will need to build extensions to replace bits of DSL that currently exist, should they wish to retain them.
I can surely see the benefit here. It seems like it could produce your ultimate Remaster, whatever that may mean to you.
Posted by lucky13 on June 17 2008,21:02
| Quote |
| I can surely see the benefit here. It seems like it could produce your ultimate Remaster, whatever that may mean to you. |
That's part of the idea. The more modular it is, the more freedom and control over it YOU will have whether you want remasters or to use it however you want. It also means fewer 'pieces' in the core to maintain so it can stay relatively fresh and easily updated. All that and better modern hardware support...
Posted by roberts on June 17 2008,22:17
cmanb wrote| Quote |
| ... But the extensions that currently exist will work with Tinycore, right? |
No. Not necessarily. There is no libc5 in tiny core. There is no gtk1 in tiny core. These can be made into or combined into extensions.
It is for the above reason that I have decided to change the extensions filename extension. I have gone through this once before when everyone expected all extensions of DSL to run in DSL-N. Well, this time I don't want to hear it.
I am looking at using lzma and the extension of .tlz in lieu of .dsl/tar.gz. I will post, as an example only, a gtk1.tlz, emelfm.tlz and dillo.tlz. I do not want to compete in the extension area. I would rather let that remain the community's domain.
We will need a new section of the repository for core. I will be setting that up shortly. Once existing extensions are known to work with core then they can be repacked using lzma so that core is able to process them.
Tiny Core is like clivesay said,
| Quote |
| It's not going to be for the new Linux user. |
And like what lucky13 said:
| Quote |
| It also means fewer 'pieces' in the core to maintain so it can stay relatively fresh and easily updated. |
Tiny Core will be known as dslcore. It is not DSL v5. It is not going to be immediately useful. It is being released to leverage the community's knowledge of the mydsl extension system and inbuilt tiny gui widget set of fltk used alone or via Lua.
Posted by mikshaw on June 18 2008,00:15
Once this new dslcore and repository section are in place, I will likely not be involved with updating any past extensions or scripts that were designed for DSL, since dslcore is what I have been hoping for since I first found DSL. My focus will likely be on dslcore only. Of course the scripts I wrote for DSL are completely open, so anyone who wants to maintain them for DSL is welcome.
Posted by ^thehatsrule^ on June 18 2008,02:13
Heh, I was going to suggest "core" as the new name, but thought it might to used too much already (i.e. in processors). "dsl-c" for short then?| Quote |
| There is no libc5 in tiny core. |
Posted by chaostic on June 18 2008,06:47
| Quote (mikshaw @ June 17 2008,20:15) |
| Once this new dslcore and repository section are in place, I will likely not be involved with updating any past extensions or scripts that were designed for DSL, since dslcore is what I have been hoping for since I first found DSL. My focus will likely be on dslcore only. Of course the scripts I wrote for DSL are completely open, so anyone who wants to maintain them for DSL is welcome. |
You should post a list of which scripts you currently take care of then :P
Posted by chaostic on June 18 2008,06:51
| Quote (roberts @ June 17 2008,18:17) |
| snip |
Just to avoid confusion, will there be a shell aside from the ftk/lua combo? Bash? Ash? Busybox's shell?
Posted by ^thehatsrule^ on June 18 2008,06:58
The other thread(s) indicated some version of ash iirc. (afaik busybox's is also some variant of this)This thread's now turned into another... oh nevermind :P
Posted by lucky13 on June 18 2008,13:37
Since it's come up and without getting too far ahead of ourselves, maybe it's time to start staking out "turf" for core extensions so we have an idea of who wants to do what. That way we have more cooperation where possible, reduce overlap of effort, get on the same page about dependency extensions, etc.
Posted by clivesay on June 18 2008,14:04
lucky13, I think you bring up a good point. It appears that once Robert gets John's blessing we will be ready to start doing some testing judging from some of his posts. Robert, when you post the core for us to test, do you mind creating a thread in the extension area specifically for DSLCore extension development? We can use that as a discussion area on who is working on what.
Geez, it's been so long for me, I'm going to have to go back and review my old build notes!
Needless to say, I am excited to start working on this project as it is something that some of us have been talking to Robert about for probably 3yrs now.
Posted by curaga on June 18 2008,14:17
I'm eager to get to try it too.Pre-pre-reserving OSS4 sound support extension
Posted by Jason W on June 18 2008,15:46
| Quote |
Since it's come up and without getting too far ahead of ourselves, maybe it's time to start staking out "turf" for core extensions so we have an idea of who wants to do what. That way we have more cooperation where possible, reduce overlap of effort, get on the same page about dependency extensions, etc. |
I agree. We need for the extensions to fit together in a coherent system and not have duplicate libraries overwriting each other or being redundant in the self contained apps. My preference is to factor out things such as gtk2, graphics libraries (png,jpeg,tiff,etc.), SDL, SSL/SSH, and so on and so forth. It makes for more extensions to load, but makes for a cleaner system. Especially for those that install across the file system like the present .dsl. Not as convenient as having every extension being self-sufficient, but makes it easier to keep extensions up to date and a smaller overall footprint of the installed extensions. This would mean that the lower level libraries need to be ported or built first, and then the higher level apps later.
The exception to factoring may be ones like gtk2. We may want to keep gtk2 as standalone, not depending on a bunch of other extensions.
I will be porting the extensions I have made for DSL 3x/4x to core once it is released. May not be done overnight since as mentioned above there will be libraries that I will have to wait on such as the graphics libs. Gtk 2.12.9 (and also Felson's 2.10.9) *should* work if they are converted to the newer extension format. I will port gtk+-2.12.9, rebuilding or adding to if necessary, but I will not be offended if anyone makes the more recently released 2.12.10. Or just improves upon 2.12.9. But preferably give me a shout so there is no overlapping effort.
Juanito's smaller gtk2 extension would be good to have as well for the basic apps that do not require a full size gtk2.
I assume this is the direction we will want to go in as far as building extensions is concerned. What do yall think?
Posted by robc on June 18 2008,17:08
I would have to say that this DSLCore is a great idea and what I was originally looking for when I started exploring Linux distros. I settled on DSL because of its lightweight and ability to NOT eat up compact flash drives using frugal installs. Though I ended up ripping out most of the applications that were in the base (i.e. word processing tools, fluxbox, games, browsers, etc.) since they were not needed for my application of DSL. But I also had to add a bunch of stuff like XFree, libc6, libstdc++6, gtk2, ttf fonts, and more. Having this tinycore would allow me to better support some of my hardware (usb touchscreens) while at the same time reducing the size of my system (since there is still many parts that I don't need that are included in the DSL base).I look forward to this new DSLCore and thank you for all your hard work.
Posted by curaga on June 18 2008,17:10
Before anyone can get that far, I think we need a clear word on what to use for compiling.Robert has said he used Finnix for bootstrapping. Haven't taken a look at that, but does it have a complete toolchain? Is it good for that use, or do we need a compiling extension specifically for the core?
Posted by ^thehatsrule^ on June 18 2008,17:51
Since this is a 2.6.x aiming for newer hardware etc., is there a minimum machine spec target? This info might be useful for users who are compiling extensions so that they can use optimizer flags, etc.fyi, I've had some problems with Felson's 2.10.9 extension though (for compiling stuff).
I had a giggle when lucky13 suggested "turf" - it is a good idea though. I'll just take something no one else has taken ;p
Teams focusing on certain things might be good as well... (ensuring compatibility of their extensions etc)
Posted by lucky13 on June 18 2008,20:04
| Quote |
| does it have a complete toolchain? |
I'll have to double-check, last time I used it was a version back but I recall it had everything. If not, it uses Debian-testing so it shouldn't be difficult filling in the missing pieces. We'll need Robert to provide more guidance first.
Posted by roberts on June 19 2008,02:58
Of course the murga incident affects this project as well. Who knows perhaps that was the real reason for the way in which it was handled; stop tinycore.Many programs would need to be made into fltk only programs in order to continue. That will take some time. Or an alternate be suggested, or to use only command line version of the mydsl system and release anyway.
Posted by lucky13 on June 19 2008,03:09
I probably can't start til this weekend (Friday at the earliest), but I can get to work on a whiptail/dialog front end for mydsl if that's an acceptable alternative to FLTK or any other graphical took kit.
Posted by Jason W on June 19 2008,03:16
My $.02 is that for now tiny core would be great with a command line environment for the MyDSL stuff until a replacement can be found. After all, if you cannot issue commands you will not be a good tiny core user anyway. I think the majority of DSL users would survive with it and it would be the quickest temporary replacement. And it can buy time for finding a toolkit while we are able to enjoy tiny core.You know, the timing of that crap is indeed very unsettling.
Posted by roberts on June 19 2008,03:19
OK. Sounds like a plan. BTW I am using full dialog not just whiptail.dialog-1.1-20080316.tgz
This version of dialog can even be themed. There are examples on the net.
Posted by lucky13 on June 19 2008,03:25
Thanks, I've downloaded it. I'll also put it on laptop so I can work if/when I get a chance between now and the weekend.
Posted by mikshaw on June 19 2008,03:54
| Quote |
| BTW I am using full dialog not just whiptail. |
Posted by Jason W on June 19 2008,03:59
Yeah, I noticed differences in the two as well in the small amount of whipping tail that I have done. One case where more features is nice as long as it does not take up much space or memory/cpu.
Posted by lucky13 on June 19 2008,09:19
| Quote |
| One case where more features is nice as long as it does not take up much space or memory/cpu. |
Those are two of (at least) three things to consider. The third is dependencies. It may have a smaller footprint on its own, but it won't run like that. It may not be the smallest choice when you weigh the rest of what it requires against larger binaries and what they require.
For example (I'm not sure what's in debian-utils but I presume that's set up in any install anyway):
< http://packages.debian.org/sarge/whiptail >
< http://packages.debian.org/sarge/dialog >
It all depends what else is on the system and how many libraries you can share to make it worthwhile.
Posted by mikshaw on June 19 2008,12:39
I don't know if this is what you were getting at, but it seems that dialog, when built in DSL, requires nothing that wouldn't be required by any other app (libncurses being the possible exception, but a necessity for the interface)| Code Sample |
| dsl@bungle:~$ ldd bin/dialog libncurses.so.5 => /lib/libncurses.so.5 (0x40019000) libc.so.6 => /lib/libc.so.6 (0x40055000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) |
This was built in DSL 4.3 using compile-3.3.5.uci
I assume debian-utils would include basic commands that are used by many applications, but just guessing.
Posted by roberts on June 19 2008,13:13
I would hold off from generating alot of replacement code.Mr. Murga has certainly caused an incident here, but at this point, I think a few days to cool off are needed.
During such time a thorough review by the developer of the shared library, John Andrews, and myself will then come to a decision on how we will proceed. I do not see any GPL violation. But I would like a consensus and that will take some time, as some are traveling and at the moment do not have time or access for such a review.
Posted by mikshaw on June 20 2008,02:38
Regardless of where that situation ends, I wouldn't be the least bit disappointed if whiptail was replaced with dialog in any of the DSL flavors =o)I assume dialog can be usedwith io.popen in Lua just as it can be used in bash to create hybrid X/console interfaces, and dialog really does provide much more flexibility than whiptail.
Posted by roberts on June 20 2008,15:56
I am open to any and all straight fluid/fltk or dialog+lua programs.
Posted by roberts on June 21 2008,20:24
dialog-1.1-20080316 will replace whiptail in next cut of DSL.
Posted by curaga on June 22 2008,13:36
Will libnewt be removed? AFAIK nothing else uses it, it's 110kb away..
Posted by chaostic on June 22 2008,19:02
*Stretches an incredibly old Monty Python joke*Libnewt?
Well, I got better...
Posted by roberts on June 22 2008,20:48
| Quote (curaga @ June 22 2008,10:36) |
| Will libnewt be removed? AFAIK nothing else uses it, it's 110kb away.. |
Yes, thanks for the reminder. I forgot to reference my ldd.lst.
But then, well, you know, how things have been around here for me lately. Looks like a libslang.so.1-UTF8, a link can also be removed.
Posted by roberts on June 22 2008,21:05
| Quote (clivesay @ June 18 2008,11:04) |
| lucky13, I think you bring up a good point. It appears that once Robert gets John's blessing we will be ready to start doing some testing judging from some of his posts. Robert, when you post the core for us to test, do you mind creating a thread in the extension area specifically for DSLCore extension development? We can use that as a discussion area on who is working on what. Geez, it's been so long for me, I'm going to have to go back and review my old build notes! Needless to say, I am excited to start working on this project as it is something that some of us have been talking to Robert about for probably 3yrs now. |
I really don't do that, but I will ask John.
We really should have a dslcore topic area as well as a dslcore extension area.
Right now, dslcore discussion is in several topic threads.
EDIT: Just sent a request for two new topic areas.
Posted by clivesay on June 23 2008,00:45
| Quote (roberts @ June 22 2008,20:05) |
| EDIT: Just sent a request for two new topic areas. |
Does this mean we are about ready to test?!!
Chris
Posted by roberts on June 24 2008,19:21
I am asking for these two new threads so as to have a specific place to discuss dslcore and dslcore extensions.I feel dslcore witll have a long alpha cycle, as well as a long release candidate cycle.
The first alpha cycle will be to test and discuss the core elements and possible upgrades, reconfiguration(s), and or inclusion of additional elements. As well as start a separate discussion on how to handle core extensions.
I am leaning on keeping .dsl and .tar.gz to work in dslcore, just so that an initial trasition is easier, but will likely drop in favor or .tlz?
Posted by clivesay on June 24 2008,20:50
That sounds good. I figured this would be a long cycle. Staying with the dsl and tar.gz is probably good for now but I vote to make the change you suggest, At some point, we will probably want a different extension type just to differentiate the core from the other editions.
Looking very forward to the alphas, RS.
Posted by mikshaw on June 25 2008,19:19
Until such time when the dslcore topic might be created, I suppose this thread should be the place to talk about it?This is an extension issue, though....
If you continue to use the murgaLua library + Lua + FLTK, I assume FLTK headers will still need to be available in order to build FLTK applications. I started building a new FLTK extension (1.1.9) a while ago, but put it on hold when the murgaLua lib development started. The current state is the default FLTK build such as the uci made for 1.1.7, but I have a question about what changes might need to be made in order to build FLTK apps that use the dynamic FLTK library rather than including it statically in the app (it seems that is the default behavior). Does the FLTK mydsl package need to be built in a special way, or do you need to tweak the build process for subsequent FLTK applications? In either case, could someone school me on the process?
Posted by curaga on June 25 2008,20:26
No need to change anything, as if both static and shared libs are available shared is used by default.Building FLTK you do need to specify you want the shared lib, 'cause their default behavior is static only.
Posted by florian on June 25 2008,21:30
| Quote |
| FLTK headers will still need to be available in order to build FLTK applications. |
I will make available next week a fltk-dev extension, containing: the FLTK headers, fltk-config (script sometimes required by few Makefile of some FLTK apps), the FLUID visual interface builder, and FLDEV which a tiny FLTK-based C/C++ IDE.
Posted by mikshaw on June 26 2008,13:15
I already have one built, as I mentioned (fltk.uci). It includes all of the above with the exception of FLDEV. I tend to avoid *.dsl/*.unc extensions like a sickness, so unless yours is uci/tgz I'll continue to use my own and will probably go ahead and submit it (notice there are 3 mydsl versions of fltk-1.1.7).But if your fltk-config is different than mine it may make a difference in behavior.
The main reason for asking the question is that I believe this script may need to be modified in order for it to use the dynamic FLTK library, since the headers were installed into /opt but the library is in /usr.
I'm just guessing here, though. Unless I run into trouble I generally don't do any special magic other than commandline options listed by configure --help. I don't really have any clue about how compilers/linkers work.
Posted by roberts on June 26 2008,17:38
I find fltk-config by default makes static builds which are quite large.I use command line options to g++ which results is very small binaries.
Posted by cmanb on June 26 2008,17:47
| Quote (mikshaw @ June 26 2008,10:15) |
| I tend to avoid *.dsl/*.unc extensions like a sickness, so unless yours is uci/tgz I'll continue to use my own and will probably go ahead and submit it (notice there are 3 mydsl versions of fltk-1.1.7). |
What's the qualifier here?
You like *.uci but not *.unc? You shirk *.dsl but not *.tgz?
Posted by mikshaw on June 26 2008,18:38
| Quote |
| What's the qualifier here? You like *.uci but not *.unc? You shirk *.dsl but not *.tgz? |
1) *.dsl runs mkwriteable, which adds more of the system into ram, including the extension itself. The tar.gz extensions also increase ram use, but they do not run mkwriteable and are very easily removed when I'm through with them.
2) Unionfs (unc requirement) breaks midnight commander's subshell feature, which I use constantly.
Posted by cmanb on June 26 2008,18:45
| Quote (mikshaw @ June 26 2008,15:38) | ||
1) *.dsl runs mkwriteable, which adds more of the system into ram, including the extension itself. The tar.gz extensions also increase ram use, but they do not run mkwriteable and are very easily removed when I'm through with them. 2) Unionfs (unc requirement) breaks midnight commander's subshell feature, which I use constantly. |
Gotcha. Cool enough.
And are you calling out my question as Off Topic? That seems to be unlike the ever-helpful and friendly mikshaw we all know and love here.
Posted by mikshaw on June 26 2008,21:54
yeah....I don't usually care about off-topic, but I do get paranoid/neurotic from time to time. Your post seemed to me to be a little bit aggressive (at the time), so I responded with a little bit of defensive hostility. I realize now that was silly.Hope you can look beyond my quirks =o)
Posted by mikshaw on June 26 2008,22:13
another question concerning FLTK...Should it be built with GL support? The one I have now doesn't have it because the libs/headers are not available in DSL+compile-3.3.5, but I wonder if GL support could be available in FLTK apps with one of the X or mesa extensions.
Posted by florian on June 27 2008,11:05
milkshaw, I didn't noticed earlier that you've prepared a fltk extension. If it's ok, I also continue with mine since I really want to combine it with FLDEV.On the OpenGL topic, FLTK libraries in DSL are compiled without it and this is on purpose of course. However I have one day compiled tinygl (http://fabrice.bellard.free.fr/TinyGL/) on DSL just for fun (I have weird hobbies, don't I?). And it was working very well on small examples; it may be possible to compile FLTK with GL support even when not using full X/mesa/dri/etc. Maybe it's just stupid idea (because without proper X do we really need OpenGL?), but I write it here down anyway
Posted by mikshaw on June 27 2008,13:19
As far as needing OpenGL, I'm not sure, but it just seems that some users might want to build FLTK apps that use it...they can easily add GL support to DSL for those apps. If GL is not available in FLTK, then I assume those apps won't build.| Quote |
| I have one day compiled tinygl |
Posted by florian on June 27 2008,14:31
[quote=mikshaw,June 27 2008,16:19][/quote]| Quote | ||
|
Yes it contains headers. As far I remember TinyGL does include OpenGL 1.1 and GLX header files. And it worked ok as I had compiled a few OpenGL sample against those headers and the tinygl.so shared lib! But does TinyGL provides a full GL API and header or only a subset, that I don't know.
Posted by curaga on June 30 2008,13:25
About tinyGL: the homepage says it's only a subset, but I'm more concerned with speed - it claims to be fast even though it's a software renderer. What do you get from glxgears with it? ;)
Posted by florian on June 30 2008,15:45
| Code Sample |
| About tinyGL: the homepage says it's only a subset, but I'm more concerned with speed - it claims to be fast even though it's a software renderer. What do you get from glxgears with it?;) |
I can't check this anymore since black smoke and burnt smell came out of the power supply of my P2 computer I use(d) for DSL (I'm feeling so frustrated, this old stuff had become my main computing station!)
But I remember the examples were running smoothly although those contained only a limited amount of polygons. The visual quality was pretty bad compared to Mesa.
Posted by curaga on June 30 2008,17:04
I'm just wondering, for size it would be perfect for DSL, but if there's no utility..For comparison, I get 230 glxgears fps on software Mesa rendering with a top Core 2 Duo
Posted by meo on June 30 2008,19:23
Hi guys!I'm sorry to hear what happened to your old box florian. I hope you can get restarted with DSL ASAP.
Curaga: How much RAM do you have on that machine? Pretty much I guess.
Have fun with this incredible nice distro,
meo
Posted by curaga on June 30 2008,19:55
It has 2 gigs. Should it affect 3d rendering?
Posted by meo on July 01 2008,01:18
Hi again curaga!I was just curious, that's all (I'm looking at newer laptops even if I like the one I use).
Have fun working with DSL,
meo
Posted by curaga on July 01 2008,08:27
It's a desktop. Support linux and get a laptop without the MS tax