adding new programms to compiletc

[c-coder]

Hello.

I have just booted in tiny core linux and have installed opera for surfing the net.
Everythings works great and is extreme fast.

After such a great impression i have downloaded and installed compiletc to try to compile some programms.
I am missing at the moment the Subversion Programm for fetching the source code and compile it in tcl.

Is allready somebody working to include svn to compiletc?

If not, is it possible to compile svn on my machine and to send it to somebody to include it in compiletc ?

Thanks for the help and the great work till yet.
Greetings c-coder

[^thehatsrule^]

svn will probably not be included in compiletc because it is not a tool required for compiling.

It is more likely that it would be in a separate extension should you or someone else want to create one.

[florian]

What about X headers perhaps?
Although there's already a Xorg-dev extension that one can use.

[Juanito]

I'll look at making a separate svn extension - I've downloaded the tarballs, now I just have to find the time to compile them

For the X headers - since there's both the base XVesa Kdrive and the Xorg-7.4 extension that people would commonly compile against, I think it's best the headers are separate from compiletc

[c-coder]

I have tryed to compile svn in tiny core linux.

Normally building svn from sources is not a problem,
You need the two source tarballs and install additional the openssl tcl extension.
After this everything should go easy.

For some reason however tiny core linux freeze after a while svn is compiling.
I cant move the mouse pointer nor can i write something on the keyboard.

Its pity that tiny core linux isnt such stable like i thinked itself.

I am asking my self why tcl freeze while i try to comple svn from sources .
Does somebody also has this problem ?

[^thehatsrule^]

My guess is that you were compiling in memory and ran out of it.

[tobiaus]

it would be awesome if just before running out of free memory, linux severed the network connections, kill -9'ed whatever process took up the most memory, and then gave you the option of restoring the internet connections.

it would be an os-wide version of something i've seen happen to browsers in 2.6, if not by design. it's cooler than what i used to see in dsl. when you ran out of memory or cpu was at 100, it would just stop, i couldn't even switch to tty or leave xwin. in that regard, tc is much more stable (for surfing) than dsl 4.4.2 on the same machines i've used both on.

[^thehatsrule^]

I recall that there were some reports that enabling some swap would help...

[mikshaw]

it would be awesome if just before running out of free memory, linux severed the network connections, kill -9'ed whatever process took up the most memory, and then gave you the option of restoring the internet connections.

That sounds like a horrible solution.  An operating system shouldn't shut down an arbitrary application simply because it has run out of memory.  It should merely wait until running processes have done their business.  If that means you can't do anything until those processes complete, then it is up to you to decide if you want to force certain apps to close...or force a shutdown.  The OS should never make these decisions for you.

[mikshaw]

Ok...maybe that sounded a little harsh.  I'm sorry, but I think it would be a bad idea to let the OS decide what to shut down....the user should be given the freedom to choose, even if it means a little inconvenience.

[Jason W]

Linux OOM killer is one such thing that shuts down a process before memory is exhausted and lockup occurs, but of course it can't read minds and the complaints I've read about is that it shuts down the wrong process or too many processes.  It tries to aim at the offending process that is gobbling memory.  I have also seen scripts that do the same thing.

I have to admit that when running with tce's and no /usr/local mounting I have in the past locked up my system while either compiling or simply untarring a kernel.  Compiling glibc totally in RAM on a system with 1GB memory and no swap ground it to a halt.  The solution of course is to use storage media to untar and build on and use tclocal or tcz's.  I rarely do anything totally in RAM except on the above mentioned1GB Windows only machine I sometimes have use of that has no working usb ports. 

For a remote server that you only have access through ssh or some other means and no physical access to, having the system shut down a process before locking up allowing you to ssh into it, free some memory or take care of other issues, and restart the process may be of some value.  In that case a hard lockup is the worst case scenario.

[tobiaus]

no offense taken, i'm just glad you didn't phrase it "dumb idea." that was kind.

ideally i agree with you, but when the only choice is waiting (literally) an hour for a process that never frees up the ram, or the os cuts off something using all the ram, i'll take the latter. a really great compromise was the os said "hey, i'm about to run out of ram. should i just assume that's what you want or do you want me to kill the process before you're unable to?"

as often as it happened, that would be great.

but as someone mentioned, swap helps too. in any case something so very "wouldn't it be nice" was intended only as such. wishful thinking, not a formal rfc. your idea is good, i like the combination of yours and mine the best, and there's probably some way to make it even better than that. just don't think it was very serious, it was only a thought jason: thanks for mentioning oom, never heard of it. if they take mikshaws idea that could improve it.

[curaga]

You can also monitor your ram usage by uncommenting the monitor call in your .jwmrc-tray, which by default will show percentage and update every 1.5s.

[Juanito]

..and BTW the "..0%S" works nicely with no swap now - thanks

[tobiaus]

You can also monitor your ram usage by uncommenting the monitor call in your .jwmrc-tray, which by default will show percentage and update every 1.5s.

conky is doing a fine job of that. it doesn't become a problem so much because of not monitoring, but because an application, usually a browser (i tried different ones, dillo did it more than firefox!) would not want to surf too much without hogging all the ram, even if i cleared the cache, history, turned off picture loading. this was more of a problem with dsl and 2.4 kernels (whether by cause or coincidence) although it happened with dsl-n too. i'm happy to say tc seems a lot better about it. maybe ff3 is more stable than the versions of ff2 i was using with dsl? seems likely. although i liked ff2 a lot.