wish list for the new version, dsl 5.0
Forum: DSL Ideas and Suggestions
Topic: wish list for the new version, dsl 5.0
started by: tagori
Posted by tagori on May 03 2008,07:01
hellois it possible to add the 'mount-tool' which we have use in the 3.x versions?
i mean the tool which you can find in the corner (right side, at the bottom).
< http://damnsmalllinux.org/dsl-3.1.jpg >
kind regards, alex
Posted by jpeters on May 03 2008,15:45
| Quote (tagori @ May 03 2008,07:01) |
| hello is it possible to add the 'mount-tool' which we have use in the 3.x versions? i mean the tool which you can find in the corner (right side, at the bottom). < http://damnsmalllinux.org/dsl-3.1.jpg > kind regards, alex |
It's included now; use Emelfm and right click.
(or just right-click on any desktop icon).
Posted by tagori on May 03 2008,16:02
it would be more easy if we could use the graphical tool.
Posted by ^thehatsrule^ on May 03 2008,17:15
He's asking for the future DSL... which may or may not include emelfm/dfm.
Posted by roberts on May 04 2008,02:27
mount.lua, being a small lua script will return in tiny core.Tiny core has no gtk1 or gtk2 so, no emelfm in base.
No icon manager is either.
Tiny core will not be useful without the community created mydsl extensions.
While it is possible, make that likely, that one or more prebuilts (core + mydsl apps) will be made available, that is not what I am woking on and would come later.
Posted by jpeters on May 04 2008,18:44
| Quote (roberts @ May 04 2008,02:27) |
| Tiny core has no gtk1 or gtk2 so, no emelfm in base. |
How about MC?
Posted by kuky on May 04 2008,22:07
I wanted that a world contest was done for the v5 backgrounds...to improve the relations of dsl community and no dsl users...The theory of social networks says that always there is a cousin or another relative who can do photos or designs...only is needed to fix the size of jpgs about 100 kb ??
Posted by roberts on May 13 2008,06:26
Update:After proof-of-concept, I am still compiling from sources and assembling the system.
My attention will be diverted back to 4.x and the new lua_fltk from florian.
The new lua-fltk will also need to be in tiny core.
I don't think I should call this new base DSL v5.
It is not a complete desktop.
It is just enough to boot into tinyX/JWM and fetch/install mydsl extensions & modules.
Together with the familiar DSL way of boot options, backup/restore and some simple tools, mostly lua and lua_fltk stuff.
It is a much simpler system and hopefully no pre-existing libraries will be in the way for supporting a great collection of user contributed extension.
Each day progress.
Posted by tagori on May 13 2008,06:35
does the new version support better the eee pc?
Posted by Juanito on May 13 2008,06:42
| Quote |
| It is not a complete desktop. It is just enough to boot into tinyX/JWM and fetch/install mydsl extensions & modules. |
- sounds good, dsl-3.x and dsl-4.x are already great desktops. As several of us are discovering (posts on gtk+, etc) in some ways, the less there is in the base, the easier it is to add stuff...
..and if the tiny base is compiled from source, we will be sure of its orgin for libs/headers/etc
Posted by tagori on May 13 2008,09:05
hellothe number of the version is not that important. but the stability and the hardware detection must be great.
please include the drivers for the hardware of the asus eee pc (at least the wlan-modem). this little computer is just great. damn small linux would be the perfect system for the eee pc.
regards, alex
Posted by curaga on May 13 2008,14:07
Since the tiny core won't include a toolchain, which extension you will compile the kernel with?
Posted by roberts on May 15 2008,20:02
The toolchain that I used to compile the kernel and start compiling other major components was by bootstrapping from finnix 91.1, gcc-4.2.3. The new system is nothing like finnix/knoppix but was an easy way to bootstrap the tools I needed to compile the kernel and other major components.
Posted by florian on May 16 2008,18:21
| Quote |
I don't think I should call this new base DSL v5. It is not a complete desktop. It is just enough to boot into tinyX/JWM and fetch/install mydsl extensions & modules. Together with the familiar DSL way of boot options, backup/restore and some simple tools, mostly lua and lua_fltk stuff. |
We're all looking forward to learning more about Robert's work. It's so exciting!
I also started to wonder how much of a desktop we would be able to build with only what's included in tinycore (x11 + fltk + lua and extensions). A very light desktop depending on only those libs would be awesome ;)
So after a quick Google search, I have found two desktops based on FLTK:
* The Equinox Desktop Environment (http://equinox-project.org/) looks very polished and shiny. It is now based on an modified (extended?) FLTK but according to the website the next release will be based on standard FLTK 1.1 present in tinycore.
* XD640 (http://www.oksidizer.com/software/xd640.html) seems very lightweight and minimalist. It might be an unfinished/abandonned project. And it also uses some patched version of FLTK that adds custom widget and handles utf-8 so in this case some dev might be needed to make it compatible with FLTK in tinycore. Yet, this is very interesting; I might try to "fiddle" with it at some point next week.
Posted by lucky13 on May 16 2008,18:30
| Quote |
| The Equinox Desktop Environment (http://equinox-project.org/) looks very polished and shiny. It is now based on an modified (extended?) FLTK but according to the website the next release will be based on standard FLTK 1.1 present in tinycore. |
IMO, ede is a step down from jwm. Last time I tried it (approximately 2-2.5 months ago), it continually crashed. That led me back to jwm and then to try dwm.
Posted by roberts on May 16 2008,18:37
I do indeed think tiny core can be a wonderful playground for lua fltk and with florian's new "open lua fltk" it will be even better. 
And with the option of gtk1 or gtk2 we will be able to deploy the community built extensions, while more lua fltk and/or fltk apps can be made and come into tiny core.
Posted by florian on May 16 2008,18:38
| Quote |
MO, ede is a step down from jwm. Last time I tried it (approximately 2-2.5 months ago), it continually crashed. That led me back to jwm and then to try dwm. |
Ho! I knew there was a reason why EDE's look was so alike Win95
Posted by clivesay on May 16 2008,20:06
There was a small distro I played with awhile back that used ede. It also had troubles with the occasional crashing. Seems it had potential but just needs more work. When it comes to light, I am always going to be partial to fluxbox. With tiny core you can "ship" DSL with any preinstalled desktop extension and no one would know the difference whether it was in the actual core or not unless they fished around in the iso.Can't wait for the testing to begin!
Chris
Posted by lucky13 on May 16 2008,20:59
| Quote |
| There was a small distro I played with awhile back that used ede. |
Saxon, perchance?
| Quote |
| With tiny core you can "ship" DSL with any preinstalled desktop extension and no one would know the difference whether it was in the actual core or not unless they fished around in the iso. |
I think users will come around to embracing the modularity of it. It gives as much choice and control as is possible to the user while still allowing DSL to be used as live CD, etc.
Posted by clivesay on May 17 2008,02:40
Saxon, that's it. I couldn't remember the name of the OS. Chris
Posted by florian on May 20 2008,22:15
Has uclibc been considered for tinycore? uclibc could make a great deal of size difference for tinycore. And as tinycore is built entirely from source, compilation with uclibc could be possible, couldn't it? Also as tinycore is a departure from previous DSL version, I believe compatiblity is much less of an issue.
If anything is required to check if tinycore would benefit from uclibc, I'm willing to give a hand.
DeliLinux (http://www.delilinux.de/) is a mini desktop linux distro using uclibc and according to the website runs all its graphical apps smoothly with a 486 and 16Mb Ram.
Posted by mikshaw on May 21 2008,11:42
Maybe this was mentioned, but I don't remember....Would existing extensions be compatible with uclibc? If not, it would be a big problem.
Posted by clivesay on May 21 2008,12:50
I guess I had been thinking that DSL 5 would be a big enough departure from the other versions that new extensions would need to be built. Many of the existing extensions wouldn't be attractive to use because the new structure of the core will allow the use of much more updated versions of the apps in the existing extensions. Does this sound right?
Chris
Posted by Jason W on May 21 2008,13:21
My thoughts are that even though there are many extensions that would have to be rebuilt or just reworked for the 5.0 series anyway, going with uclibc would increase the headache factor of building extensions quite a bit. Even if the base system worked well with it. And many things like Opera that are only available as binaries would not work or work poorly. That seems to be the reasons Puppy Linux ditched uclibc earlier:< http://www.murga-linux.com/puppy....fe37754 >
I only have had brief experience with uclibc, so if I am wrong or if anyone else has had a more pleasant experience with it I would like to hear. Uclibc, like busybox, has its place and purpose. But I far prefer dealing with glibc if I have a choice.
Posted by lucky13 on May 21 2008,13:44
My limited experience with uclibc was frustrating, too. It's not a 1:1 replacement for glibc. Most programmers of commonly used applications and utilities write with a presumption that their code will be compiled against glibc.I don't think average users should have to learn C to tweak *standard* code so they can compile against a non-standard library when the same *standard* code will compile using standard tools and libraries. What may be ideal or acceptable in an embedded environment doesn't always scale well for desktop use (and vice versa -- which is why uclibc and dietlibc and so on exist). Unless there's a primary goal of making tiny core oriented for embedded use (I hope it remains targeted at desktop computer use), I hope we can stay away from uclibc.
Posted by clivesay on May 21 2008,14:13
good feedback, guys. I am not great at compiling anyway, so I was not aware of the pitfalls. Obviously, we want extension building to be a fairly straightforward process so that the community will be able to contribute without becoming frustrated with an overly difficult process.
Chris
Posted by lucky13 on May 21 2008,14:38
I think curaga linked to detaolb, which is a Linux 2.6-based live CD (targeted at embedded/virtualized environment use) that uses uclibc. I downloaded it to check it out some time ago but never bothered burning to CD. I just mounted it to see if I could see what came with it and was surprised at the number of included apps ("modules"). Obviously, uclibc can be made to work in such an environment. I just don't know if the size savings would be worth the aggravations of compiling everything against a non-standard C library.If anyone wants to look at detaolb (and maybe compare file sizes and such between it and DSL where possible), its link is:
< http://detaolb.sourceforge.net/ >
Posted by curaga on May 21 2008,16:07
My impression of uclibc was generally positive; I got space savings way above those mentioned in that Puppy thread, about one third at best. It had some outstanding bugs however, which prevented me from going forward with it. They have since been fixed in cvs, but other stuff has probably been broken, and there has been no new release since May 2007.
Posted by florian on May 21 2008,16:45
I have not played with uclibc, so I don't have experience of it yet. But if ublibc is a compliant standard libc implementation, I'd be suprised if a lot of apps wouldn't be able to compile with it. Also if uclibc is provided in the base, a glibc.dsl extension could probably be provided for the apps that prefer to be linked against glibc.I'm not necessarily asking that DSL would be uclibc-based. I just thought that as tinycore is being prepared, it's perfect timing to give it some thoughts as this is the type of idea that really could push the envelope. Well, I'm happy I've raised the subject as there are already quite many opinions here.
Posted by curaga on May 21 2008,17:26
All libs would need to be compiled for the specific libc, so a glibc.dsl would become quite huge, not to mention it would need to have a different prefix to avoid overwriting all libraries expect libc.
Posted by humpty on May 24 2008,17:33
I think ideas like uclibc is good for discussion cos I feel there seems to be a sort of consensus that v5 might well be different enough to break away from v4- in many areas. However, veering away from the 'norm' is not neccessarily beneficial.My dream would be for are generic extension type in the form of
tar.gz s. Media space is so cheap these days, I feel there isn't much need to mount stuff to save space. And the extensions could also be used on other linux-i386 systems and be easier to develop.
All extensions would be standalone, including icons, menus..etc.. in their own directories. They would not have to be loaded, just 'scanned'. So this would be a sort of hard disk type installation (except that there is no installation
).Ofcourse there will be apps that can't meet that criteria, so .dsl loading needs to be kept. The thing I like about .dsl s is that they are really tarballs and can easily be shared with the rest of the linux community.
Also, the .info files for the extensions will be important because of the requirements they need from other extensions.
Posted by curaga on May 24 2008,18:00
When I looked into uclibc and spent time daydreaming, I thought about a new format which would combine .info, menu, icon if any, and also be a freedesktop standard.The .desktop files, which all freedesktop-compliant wm's use to create icons and menus.
The standard says any key that begins with X- is whatever you like, spec-compilant, and read only by the ones that want it.
Here's an example file:
| Quote |
| [Desktop Entry] Encoding=UTF-8 Name=Gnuchess Comment=A strong chess game GenericName=Chess Exec=eboard Icon=/opt/chess/chess.png Type=Application Categories=Game;BoardGame; X-extension-creator=Me X-description= A nice app I think X-description= will benefit the X-description= DSL community |
And it could be parsed for wether an icon or even a menu entry is wanted, etc.
Just another wacky idea
Posted by ^thehatsrule^ on May 24 2008,18:14
I recall that there were several discussions on uclibc. I would prefer (to keep) glibc mainly because it is the standard.I gave this idea out sometime ago: the use of a lighter shell (i.e. in the place of bash in /bin/sh) could yield some results. This < thread > reminded me of it.
Posted by lucky13 on May 24 2008,19:14
@hats...| Quote |
| 4. Size comparisons Shell In-memory size (kB) Binary size (kB) ------------------------------------------- ash 472 97 bash 1400 533 ksh 1212 834 tcsh 1448 292 zsh 1472 424 All binaries were stripped. The in-memory size is obtained from the RSS column from 'top'. Sizes may vary slightly from system to system and also depending on exact shell version. I am actually not certain how relevant these figures are, but decided to include them for comparison. Another thing to keep in mind is that zsh uses a lot of modules that also takes up space, so the total disk space needed are higher than the above figure. The total zsh installation uses over 3 MB. |
< http://www.linuxfromscratch.org/hints/downloads/files/OLD/shells.txt >
Posted by roberts on May 24 2008,19:31
I am mainly using tar.gz as the supported extension type. I am using a lighter shell. I am mainly using kernel+busybox+lua+fltk+jwm and not much more.I am trying to be backward compatible with exsiting DSL, i.e., I have a gtk1.tar.gz which when mydsl-load'ed works. Then mydsl-load emelfm (gtk1) and dillo all works. So one could run a smallish gtk1 system.
The effort that the community has spent learning UCI, mountable self contained compressed applications, could still be supported only uncompressed. This being the case to provide an easier means to make and use, no read-only stuff, open to being used in other systems, and still have the advatage of low ram usage. I would even be interested in supporting other systems self contained application/receipies except as mountables But I think we have enough of our own community made to begin with.
To change or combine the info/icon/menu to a new standard would be an impact to the community. I of course could accomodate in tiny core - but think about the impact to exsiting users who wish to remain with 3.x/4.x. Of course, we could just abandon them, like the other distros have, and only look forward. Maybe that will happen anyway, not sure. Look at those who cling to v3.x. I am surprised that someone hasn't made an xtdesk.dsl for 4.x.
I cannot, as one person, offer and maintain, so many editions of DSL and then compound that with maintaining multiple "edition specific" repositories.
Tiny core is progressing nicely, I have renamed backup.tar.gz to mydata.tar.gz so that tiny core and play nice alongside DSL.
Posted by mikshaw on May 25 2008,02:02
| Quote |
| I am using a lighter shell. |
It would be nice to know in case we want to familiarize ourselves early with any differences to bash.
| Quote |
| The effort that the community has spent learning UCI, mountable self contained compressed applications, could still be supported only uncompressed. This being the case to provide an easier means to make and use, no read-only stuff, open to being used in other systems, and still have the advatage of low ram usage. |
| Quote |
| I am surprised that someone hasn't made an xtdesk.dsl for 4.x. |
| Quote |
| I cannot, as one person, offer and maintain, so many editions of DSL and then compound that with maintaining multiple "edition specific" repositories. |
Posted by curaga on May 25 2008,08:00
| Quote |
| Would you be talking about using uncompressed ISO9660 (mkiso) then? |
Puppy might be a good example too, as many of it's editions are completely kept up by volunteers, and they all share and prosper happily along.
Posted by mikshaw on May 25 2008,12:51
| Quote |
| Isn't iso9660 still readonly? |
Posted by curaga on May 25 2008,13:18
I guess the difference between a .map and a .tar.gz is the unpacking - saves time just to mount.
Posted by tagori on May 25 2008,16:26
helloplease add more drivers for wireless cards (especially for the eeepc).
regards, alex
Posted by lucky13 on May 25 2008,16:47
| Quote |
| please add more drivers for wireless cards (especially for the eeepc). |
Such modules should be extensions. There are too many cards to support, and this shouldn't be an eee-oriented (or any other single computer model) distro. I would take ndiswrapper out, too, and let users who need it get it from MyDSL.
Posted by humpty on May 25 2008,17:41
| Quote (curaga @ May 25 2008,21:18) |
| I guess the difference between a .map and a .tar.gz is the unpacking - saves time just to mount. |
Seems to me like the only advantage for compression is for smaller
files for distribution. The files have to reside somewhere eventually,
and compression would only benefit the older devices with limited
capacity, say a 10MB hard disk. The programs all load to ram at
full space don't they? (perhaps I am wrong here).
Hence stay with tar.gz for distribution and go for permanent self-contained installation.
Also, is it possible for mydata.tgz so that the backup files can be
manipulated in freedos (8+3) ? (infact, is fat16/32 still on the cards?)
Posted by roberts on May 25 2008,18:19
mikshaw wrote:| Quote |
| Which shell would that be? ash? zsh? ? It would be nice to know in case we want to familiarize ourselves early with any differences to bash. |
ash. I have had to change only one script so far, actually it was in the dsl-functions and I had used some arithmetic with (( )) and changed it to expr. Most other scripts are runnning without change, backup/restore, dsl-config, mydsl loading, etc...
Posted by roberts on May 25 2008,18:24
curaga wrote:| Quote |
| Puppy might be a good example too, as many of it's editions are completely kept up by volunteers, and they all share and prosper happily along. |
I would not wish to have this model of many forks and many repositories. I would hope that our close community can stay together, here, in these forums and build upon the mydsl extension system. Perhaps other isos could be hosted for download from community built extension collections.
Posted by roberts on May 25 2008,18:32
| Quote (lucky13 @ May 25 2008,13:47) | ||
Such modules should be extensions. There are too many cards to support, and this shouldn't be an eee-oriented (or any other single computer model) distro. I would take ndiswrapper out, too, and let users who need it get it from MyDSL. |
I whole heartily agree with Lucky13's statement.
One reason I don't want to call this DSL v5.x is that it breaks with the DSL tradition of a complete desktop together with hundreds of modules.
Tiny core is really tiny and not very useful by itself. One should be able to easily download tiny core and a collection of desired extensions and/or modules. Only then will one have a useable system. Don't expect many modules, or fonts, or keymaps, or languages. Expect a tiny system to boot into X and run mydslBrowser. I expect tiny core to have a rather long alpha cycle before even a release candidate is ready. I will fight hard to keep tiny core a "just enough" system and everything else an extension.
Posted by roberts on May 25 2008,18:48
| Quote (humpty @ May 25 2008,14:41) | ||
Seems to me like the only advantage for compression is for smaller files for distribution. The files have to reside somewhere eventually, and compression would only benefit the older devices with limited capacity, say a 10MB hard disk. The programs all load to ram at full space don't they? (perhaps I am wrong here). Hence stay with tar.gz for distribution and go for permanent self-contained installation. Also, is it possible for mydata.tgz so that the backup files can be manipulated in freedos (8+3) ? (infact, is fat16/32 still on the cards?) |
I will adopt the 8.3 and call it mydata.tgz.
I am mainly supporting the .tgz extension type. But my thoughts on the self contained are the following:
1. There is a difference from the usually static collection of files and directories that make up an extension and their run time memory consumption. With a tgz both the actual files and directories and the run time would consume memory. Fine for large memory system. Bad for small memory based systems.
2. Self contained applications, or application directories could be stored on persistent media in their native state as files and directories. Only then when invoked do their run time memory demands come into play. This should greatly reduce memory demands. They would need to be mounted to become part of the run time filesystem.
3. In regard to number 2 above, I was thinking of a highly compressed download and then store uncompressed and in a write enabled state. We could stay with using mountable iso9660 read-only images. But what would be the benefit? Perhaps the benefit is that the write enabled areas that we have already become familiar with are more easily included in the backup if links are created to a single simple location. Otherwise one would have to maintain a growing filetool.lst file. I am still open to ideas here. I plan to release an early alpha with only number 1 supported.
Posted by tagori on May 25 2008,19:10
i really think that madwifi is the solution for the eee pc. what do u mean? or is it better to wait for a new version of damn small linux?
Posted by lucky13 on May 25 2008,19:29
| Quote |
| i really think that madwifi is the solution for the eee pc. what do u mean? |
This can't be targeted at specific computers; it has to be broad enough to support lots of computers. With the size of the 2.6 kernel, that means that some support will come from MyDSL module extensions rather than be included on the ISO.
If I'm reading Robert correctly, it wouldn't support specific hardware straight off the ISO aside from the most common hardware (e.g., PCI, USB, etc.). You'd download the ISO and any peculiar drivers (modules) you need from MyDSL. If you need madwifi, you'd download that separately from the ISO but probably burn it to the same CD like the MyDSL remaster script. That way you can run bootcodes or bootlocal for your particular modules.
In a sense and assuming it's comparable to DSL status quo, you'll end up with a CD (or frugal install or USB-HDD) that will be relatively personalized with only what your computer requires rather than a lot of modules you don't need.
I don't know if you've compiled one of the more recent 2.6 kernels, but it's too bloated to include modules for every possible wireless device.
Posted by chaostic on May 25 2008,19:32
| Quote (roberts @ May 25 2008,14:48) | ||||
I will adopt the 8.3 and call it mydata.tgz. I am mainly supporting the .tgz extension type. But my thoughts on the self contained are the following: 1. There is a difference from the usually static collection of files and directories that make up an extension and their run time memory consumption. With a tgz both the actual files and directories and the run time would consume memory. Fine for large memory system. Bad for small memory based systems. 2. Self contained applications, or application directories could be stored on persistent media in their native state as files and directories. Only then when invoked do their run time memory demands come into play. This should greatly reduce memory demands. They would need to be mounted to become part of the run time filesystem. 3. In regard to number 2 above, I was thinking of a highly compressed download and then store uncompressed and in a write enabled state. We could stay with using mountable iso9660 read-only images. But what would be the benefit? Perhaps the benefit is that the write enabled areas that we have already become familiar with are more easily included in the backup if links are created to a single simple location. Otherwise one would have to maintain a growing filetool.lst file. I am still open to ideas here. I plan to release an early alpha with only number 1 supported. |
What about onthefly loading? Instead of downloading, saving to /tmp, then loading it with mydsl, can some packages (tgz or dsl) just be piped from wget to tar?
| Code Sample |
| wget $dslpackageurl -O - | tar -xzvf - |
Posted by curaga on May 25 2008,19:42
| Quote |
| What about onthefly loading? Instead of downloading, saving to /tmp, then loading it with mydsl, can some packages (tgz or dsl) just be piped from wget to tar? |
Posted by meo on May 26 2008,22:01
Hi Robert!Just a quick question about the tiny core project: Will the DSL 4.4 cycle come to it's end before you release the alfa of the tiny core? The tiny core project seems so exciting.
Have fun and hang on to the tiny core project,
meo
EDIT: PS I'm not clinging to the DSL 3.xx anymore DS
Posted by roberts on May 27 2008,04:25
Probably the first alpha of tiny core will post before a final 4.4.Even though I would like 4.4 final out right away, because it is so much better than 4.3 due to the change in Lua/Fltk. I would like to have one more 4.4RC2 before final.
Posted by meo on May 27 2008,06:36
Hi again!Thanks a lot for your response. I really look forward to the tiny core release.
Have fun making DSL progress,
meo
Posted by roberts on June 09 2008,03:33
Lots of progess to report.Booting, backup/restore, loading .dsl and .tar.gz extensions, most of the menu and control panel updated. Running from live cdrom, running from pendrive.
It feels like DSL. Just app'less.
Seems most basic DSL functionality is working.
Last outstanding issue is to update lua/fltk to use current libraries. Currently I have had to "double up" by using the old libraries in DSL v4. I am working on this with help from Florian. Once this is resolved I will post the first alpha cut.
Be warned. Many will say it is too small!
My goal was to host the minimum to boot into Xvesa/Xfbdev + minimal window manager, and run Lua and Lua/Fltk to support much of the MyDSL extension system. No Gtk1. No Gtk2. Not many modules. Not many tools or libraries. Very bare bones. Not much more than busybox v.1.10.3 + kernel.
Posted by Juanito on June 09 2008,04:06
..sounds a bit like where I am with LFS (which I'm trying out to prepare myself for the new dsl)
Posted by jpeters on June 09 2008,07:36
| Quote (Juanito @ June 09 2008,04:06) |
| ..sounds a bit like where I am with LFS (which I'm trying out to prepare myself for the new dsl) |
Why take the easy route with LFS when you could write your own kernel in assembly code?
Posted by curaga on June 09 2008,10:25
jpeters, it's really not that hard. And it's also all about learning, and so every little bit is documented.
Posted by chaostic on June 09 2008,20:55
| Quote (jpeters @ June 09 2008,03:36) | ||
Why take the easy route with LFS when you could write your own kernel in assembly code? |
Even masochist know their limit :P
Posted by roberts on June 10 2008,01:25
| Quote (roberts @ June 09 2008,00:33) |
| Last outstanding issue is to update lua/fltk to use current libraries. Currently I have had to "double up" by using the old libraries in DSL v4. I am working on this with help from Florian. Once this is resolved I will post the first alpha cut. |
Done. Now built using libstdc++.so.6 and libpng12.so.0
The issue tripping me up was a missing -lpng in the second g++ command to build murgalua-fltk.so.0.6.8
Posted by chaostic on June 10 2008,02:36
| Quote (roberts @ June 09 2008,21:25) | ||
Done. Now built using libstdc++.so.6 and libpng12.so.0 The issue tripping me up was a missing -lpng in the second g++ command to build murgalua-fltk.so.0.6.8 |
Since this is a wish list, can you add a full apache install, maybe Beryl, oh and how about iTunes? PLEASE?!
Anywayz, when you say done, do you mean that the first tinycore alpha is ready? Where at?
Posted by roberts on June 10 2008,02:42
I was thinking of switching to mikeOS. It is all in assembly. Now compiling luasockets and luafilesystem, then more testing.
ADN
RSN
Posted by WDef on June 10 2008,09:46
I see MikeOS runs on "1MB of RAM and a 386 CPU". No big wallpapers in there :=)
Posted by curaga on June 10 2008,13:17
Hmm. It related to MenuetOS/KolibriOS?
Posted by Juanito on June 12 2008,13:51
I'm not sure if I mentioned this before, but could cpufreq be allowed in the tiny core kernel config?
Posted by curaga on June 12 2008,14:41
My wishes for the default kernel:- squashfs
- ramzswap
Posted by florian on June 12 2008,16:14
| Quote (curaga @ June 12 2008,21:41) |
| My wishes for the default kernel: - squashfs - ramzswap |
I understand squashfs is some read-only compressed file system. What are the differences compared to cramfs or cloop? (I hope this isn't a stupid question!??)
Posted by curaga on June 12 2008,16:48
It compresses better than either of cloop and cramfs. It's pretty much evolved cramfs, and it has none of cramfs's limitations (8bit gids/uids only, or max uncompressed size of 256mb) nor the biggest flaw in cloop (you have to have enough ram/swap to fit the entire unpacked fs for either packing or unpacking)Oh, and ramzswap is swap in a compressed ramdisk. So you're trading some cpu time for more ram. Since it's the deflate algorithm, you can get about 24mb of stuff to fit in 16mb of ram.
Posted by chaostic on June 12 2008,22:32
| Quote (curaga @ June 12 2008,12:48) |
| It compresses better than either of cloop and cramfs. It's pretty much evolved cramfs, and it has none of cramfs's limitations (8bit gids/uids only, or max uncompressed size of 256mb) nor the biggest flaw in cloop (you have to have enough ram/swap to fit the entire unpacked fs for either packing or unpacking) Oh, and ramzswap is swap in a compressed ramdisk. So you're trading some cpu time for more ram. Since it's the deflate algorithm, you can get about 24mb of stuff to fit in 16mb of ram. |
3:2 compression? So for 64mb actual ram, you get 96mb. For 128mb you get 172mb. That's awesome.
Too bad it needs 2.6.x (.17 according to one report), so only tinycore would be able to use it.
The project's name is actually compcache < http://code.google.com/p/compcache/ >
ramzswap is just the name of the block device it creates.
Posted by jpeters on June 13 2008,04:59
I believe Puppy uses squashfs for their pup-save file.
Posted by curaga on June 13 2008,08:11
Of course you can't just say you will use all your ram for swap, you need to leave some for running apps and the kernel, but using it might prove handy on many machines.And yes, Puppy has used squashfs a long time, also for their main image. Not sure about 4, haven't tried it.
Posted by jpeters on June 13 2008,08:41
| Quote (curaga @ June 13 2008,08:11) |
| And yes, Puppy has used squashfs a long time, also for their main image. Not sure about 4, haven't tried it. |
4.0 has a pet2sfs script for apps (mount by clicking) in addition to a gui bootloader utility for loading sfs files at bootime.
Posted by WDef on June 16 2008,22:49
Regarding compcache:Does anyone know much about this? For eg if it is being used at scale on any distros or embedded systems? Is the developer associated with OLPC?
Posted by WDef on June 19 2008,22:22
Update: it is being included in Ubuntu Intrepid.
Posted by curaga on June 22 2008,13:19
Is it used automatically, and if so, how much is allocated?
Posted by jpeters on June 22 2008,15:47
| Quote (curaga @ June 22 2008,13:19) |
| Is it used automatically, and if so, how much is allocated? |
Seems like you can adjust; found this..
"2) compcache uses kernel memory, which is limited to 1GB on i386. To ensure we don't run out, I limit the compcache size to under 200MB so less than 100MB of kernel memory is used. (The compression ratio for the liveCD seems to be robustly 2:1).
Posted by curaga on June 22 2008,15:54
I stumbled upon another nice tool: Xtoolwait. Haven't yet tried it, but having faster X startup might be nice too.
Posted by gammelmarakuja on July 08 2008,10:18
I would like to see the mount tool back aswell...liked it more and emelfm by opening folders from the desktop. And propably some updates like 3ddesk, if it would go with the 50MB ... will all the next DSL's be 50 mb or is it gonna go higher? just so there are more possibilities. And kernel 2.6? You could include a newer version of Firefox traight ahead and also Flash could be include from the beginning. And instead of giving the choice between xvesa and xfbdev you could include xorg which most machines use nowerdays (i dont but still). And even though jwm and fluxbox are quite cool you could include something else...some eye-candy ;)I had a nice one but i forgot the name...thats it for the first
if i will think of something i will let you know
Posted by curaga on July 08 2008,12:33
You just described some entirely different distro, *cough* ubuntu *cough*, or something else like Xandros or Mint.. Most of that starting from 3ddesk is just not DSL IMO.
Posted by lucky13 on July 08 2008,12:36
| Quote |
| You could include a newer version of Firefox traight ahead and also Flash could be include from the beginning. |
Nuh uh. The idea behind dslcore is that YOU can do that if you want. It's not going to come with all that crap. Certainly not Flash, which isn't even open source.
Posted by ^thehatsrule^ on July 08 2008,17:09
mount.lua is still there (though you may have problems using it)
Posted by roberts on July 08 2008,18:45
Please refrain from discussing dslcore (currently alpha level) in other than the appropriate forum area. If have issues or concerns with its development posting details in that forum area will be most helpful.
Posted by roberts on July 08 2008,18:50
I thought about closing this topic area because there is not going to be an official DSL v5, at least not from me.dslcore is in early alpha development. What may happen, or would be desireable, is that a "DSL v5" emerges as a community edition or editions built upon dslcore. dslcore is just beginning so too are the tools and extensions. The DSL community is building the next DSL.
Posted by gammelmarakuja on July 16 2008,10:28
Aww 
i acctually liked the idea of combining the strengths of dsl 3 and 4 and making it dsl 5..like an even better DSL...propably the best DSL ever build ;) and dsl core is nice and so on, but can it replace the real DSL? in the end installing all the applications on our owns will take quite a while and having them already complied and installed would be time saving and stress saving
Posted by roberts on July 16 2008,15:59
I guess you missed the "Community Edition" statement.
Posted by jpeters on July 19 2008,03:13
| Quote (gammelmarakuja @ July 16 2008,10:28) |
| Aww i acctually liked the idea of combining the strengths of dsl 3 and 4 and making it dsl 5..like an even better DSL...propably the best DSL ever build ;) and dsl core is nice and so on, but can it replace the real DSL? in the end installing all the applications on our owns will take quite a while and having them already complied and installed would be time saving and stress saving |
If you think about it, there are already some excellent distros in which the hundreds of hours getting everything working have already been done for you, at the cost of $20 or so of extra ram. It remains to be seen how much practical use tiny DSL will have (probably not as a desktop replacement), and the people involved building it clearly have lots of time on their hands and love what they're doing.
Posted by lucky13 on July 19 2008,08:06
| Quote |
| It remains to be seen how much practical use tiny DSL will have... |
Since it's a very modular environment, its uses are only limited to the user's goals, abilities, needs, etc. For some users, it'll be quite versatile and likely be adapted to desktop use as to anything else. For those who'd rather take potshots about the perception of time others spend on certain things than to help out or be constructive, there's hyperbole and derision to dish out. Pretty clear which group you're in.
| Quote |
| ...the people involved building it clearly have lots of time on their hands... |
Some of us have quite a bit less than others. Even those distros you say invest "hundreds of hours" in development started at the point core is now with lengthy rounds of testing to fine tune things so people like you can use them. If *you* think about it, without the efforts of any of those willing to invest whatever time they do have into making things work, you'd be stuck using Windows. (Or worse, a Mac.)
Posted by Jason W on July 19 2008,15:53
JP, Robert just said to discuss dslcore in the appropriate forum for it. And you also missed the "community editions" statement too. Yes, there are distros like Ubuntu or Debian and if someone likes that kind of distro there is nothing wrong with that. Folks are free to use what they want. If a full size distro is what someone wants, they should just use one. Complaining about why DSL is too small is like complaining about why Ubuntu is too big. It does not accomplish anything. Dslcore as well as extensions for it are a work in progress, it is not totally point and click at this point. People can try out dslcore and even help out if they want, or they can wait until things are more polished. In time folks will be just a few clicks from having their favorite apps.
I for one am happy for all the time and effort that Robert has put into dslcore.
Posted by jpeters on July 19 2008,19:20
| Quote (Jason W @ July 19 2008,15:53) |
| JP, Robert just said to discuss dslcore in the appropriate forum for it. And you also missed the "community editions" statement too. |
I read gammelmarakuja's post as a response to Robert's "community editions" statement (not that he failed to read it). I thought my response stated the obvious...that tiny core is NOT an upgrade to previous versions and will probably never have what he is asking for. It certainly will never be a replacement for a MAC OS.
edit: I'm not sure how to respond to posts in an "appropriate forum"
Posted by lucky13 on July 19 2008,20:40
| Quote |
| It certainly will never be a replacement for a MAC OS. |
It damn sure will be if I ever get my hands on an Intel Mac. It would be much safer to use with (cr)Apple's stuff removed. Heh.
< http://secunia.com/graph/?type=fro&period=all&prod=96 >
< http://secunia.com/graph/?type=imp&period=all&prod=96 >
< http://secunia.com/graph/?type=cri&period=all&prod=96 >
Posted by jpeters on July 19 2008,21:40
| Quote (lucky13 @ July 19 2008,20:40) | ||
It damn sure will be if I ever get my hands on an Intel Mac. It would be much safer to use with (cr)Apple's stuff removed. Heh. < http://secunia.com/graph/?type=fro&period=all&prod=96 > < http://secunia.com/graph/?type=imp&period=all&prod=96 > < http://secunia.com/graph/?type=cri&period=all&prod=96 > |
It seems like Securia (a vender) searches through the databases of all known security issues on every piece of software on your machine..(eg, Java, the browser, Flash, Skype, etc, etc,). Meanwhile, you could be behind a hardware firewall with no ports open and show no vulnerability on tests like Shields Up.
Posted by lucky13 on July 19 2008,23:46
| Quote |
| ...you could be behind a hardware firewall with no ports open... |
Oh, the insane "Puppy defense." Which is irrelevant if you have buggy software that's exploitable either through computers on your own network or via cross scripting (XSS) and other exploits. Take a look at the changelogs for software like OpenOffice and Firefox (all Mozilla products -- popularity increases the likelihood criminals will find exploits). If you're using a browser, you're opening your computer up to exploits, firewall or no firewall. If you only browse sites that are legit and well-managed, you're probably safer than someone who indiscriminately click on links. And no, the danger isn't limited to your browser or to your OS. You can be pwned via Flash, QuickTime, etc., while using OSX, Linux, or Windows. And I suppose the more naive and gullible you are about your level of security because you think you're safer using one OS or another, the more at risk you probably are.
E.g. (and using Apple as an example of sh*tty programming that endangers users):
< http://www.gnucitizen.org/blog/0day-quicktime-pwns-firefox/ >
Posted by jpeters on July 20 2008,00:52
I suppose that means extensions are out, because you need the latest updates on all your software. OK, back to Windows...thanks..
Posted by lucky13 on July 20 2008,02:00
| Quote |
| I suppose that means extensions are out, because you need the latest updates on all your software. |
Not necessarily. While updates can include security fixes, they often contain new features or the security fixes cause bigger, more, or other issues (see Firefox). Sometimes the newer the release, the buggier and more susceptible something is. Compare Firefox 1.x and 2.x changelogs. With more complexity in code comes more potential and exploitable vulnerabilities.
Back to Windows? Vista is definitely a step up security-wise from OSX and Puppy. And all of this is way off topic now.
Posted by jpeters on July 20 2008,03:54
| Quote (lucky13 @ July 20 2008,02:00) |
| And all of this is way off topic now. |
Yes, but interesting all the same. Thanks for the lively exchange.
edit: BTW, you don't have to run puppy in root.
Posted by humpty on Aug. 10 2008,19:55
I guess I missed out on another thread about dslcore extensions.From what I've read I think the future could be far too complicated
for me and the majority of newbies. The scripts idea was not bad but
the intellectual overhead of actually installing an extension may leave
many people bewildered. Complexity can be a real killer of projects.
In view of the future that there might not be anymore ucis or dsls,
I have thus decided to make my own extensions based on the 'completely
self contained system' of opt. The key concept here is 'single directory'.
A linux single directory package (lsd) can be un-tarballed anywhere.
An lsd has all files wether it be source or binaries, .etc
under a single directory. There will be standard subdirectories for
icons, links and scripts, sources, whatever. I guess if needed some scripts
can do compilation but the idea is just plain updating of wm menus & icons.
For non-self-contained files, and let's face it, no package is completely
self-contained, the installer scripts can copy those files to the system
directories. There may also be un-installing scripts. The scripts will need
standard names for automation.
The license handling is ofcourse the responsibility of the packager, of
which there must be a standard read-me file (similar to .info).
At the moment I'm just collecting plain old tarballs or converting them
from ucis.
Posted by roberts on Aug. 11 2008,20:20
It has already been stated that things will be much different than the early alpha cut. It will not be extensions from source build scripts. The development has been moving along and when its ready, it will be ready.
Don't think that what was wil be.