Hey there, First of all, thanks a lot for the long report, this is really useful!
'2+ said : > i acutually want youtube-dl and rubberband-cli too but youtube-dl? is it CLI? rubberband-cli, make a ticket. > adding -d sid > always fails .. so yes it's lenny > > wanted to try if i could go simple > i usually use x only for iceweasle,audacity,avidemux,(wanna go kluppe someday) > and am not that realtime oriented > so i'll be happy if > python(maybe 3 is too early yet) and csound and lame works on p:d (on > almost any kind of machines) python3 ... yes too early. about csound and lame, not sure to understand, you mean they don't work? > oh so .. if am using p:d for updating the episode of my podcast > i definately want ncftp or sshfs installed as default we have lftp on p:d, I think it's better than ncftp. Maybe try it? sshfs, yes why not, make a ticket, we can add that in a future build. > recently i found that we can directly algo-comp a .wav file with > standard library of python > so i think i will gradually move from music apps to general scripting > languages > people are talking abount haskell a lot now > and i agree that hs is something when it comes to algo-dsp > but setting up a system is a big pain for non dev-er(like me)..scvim > used to be like that > (and deb also seem to lack lots of things related to hs) > SO if > ghc, hsc3, hsndfile .. could be there in p:d .. maybe this distro > would be the one and only distro Ok make tickets for these, this fits the purpose of p:d. > that will have them ready to go? > my friend built a way to do something like hsvim > http://renick-bell.blogspot.com/2009/05/workaround-for-sendtorepl-and-ghci.html > i think this will make lots of vim-live-coders happy > > but .. ghc might make the distro so phat..? > then plz consider an another one named p:h ghc would be in the liveDVD version. > oh and if booting the sys as cui 1st makes the process fast > it'll be nice for ppl using netbooks on train I need to look at the startup scripts, some stuff can be def improved. Login into X is a feature and I think we should keep it like this for the obvious "user friendliness". Also, we need to check if it's possible to use hibernate with the live system, because then it would simplify this startup speed issue quite a lot. > am personally beginning to think that > just running a script after a plain boot of any live distro to make > the system yours > (and keep that script in a top dir of ones usb-flash) > makes thing simpler than making a persistent volume > you can fix the script without booting the system > and > the script can survive forever even if the distro.iso get freaquently upgraded mmmm... this could be achieved with the live snapshot feature (untested), in which case you can maintain a small compressed file that can have persistence modification on per file basis. It's very portable and convenient compared to allocating a disk image or partition for the whole persistence. We need to look at that during the next sprint (damn it's gonna be busy! :) When it comes to updating the live system, we still need to test how the system responses and if the persistence We might have to write some cleanup scripts... I recall rob has troubles with that, but we haven't have time to look at it closer (hopefully next sprint...) > btw: > when the live-rw volume on optilex's internal hdd was there > i found that bootin from other dev-live seems to also activate it > (that p:d-logo-cui comes up) > maybe that's the default of lh_config > (cuz i put nothing related to that) yes it's normal, you could avoid that with a boot argument specifying which persistent medium you want to use and where it is located. > > (btw, this summer we will be working on some simple script that permit > > to easily customize/remix pure:dyne) > > p:d is gettin better and better! thx :) > >> and yes if i do ./setup after sudo su > >> it says that there's no such command > > > > which filesystem is used? > > is the partition mounted as rw? (type mount to check) > > this is on intrepid but: > the /dev/sdb1 is vfat(rw) > > ~# mount > /dev/sda2 on / type ext3 (rw,relatime,errors=remount-ro) > tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) > /proc on /proc type proc (rw,noexec,nosuid,nodev) > sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) > varrun on /var/run type tmpfs (rw,nosuid,mode=0755) > varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777) > udev on /dev type tmpfs (rw,mode=0755) > tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) > devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) > fusectl on /sys/fs/fuse/connections type fusectl (rw) > lrm on /lib/modules/2.6.27-14-generic/volatile type tmpfs (rw,mode=755) > securityfs on /sys/kernel/security type securityfs (rw) > /dev/sdb1 on /root/padanida type vfat (rw) > > > did you check the file is what you think it is? (type file "filename" to > > check) > > now it's renamed to "fire" but: > fire: POSIX shell script text executable > so .. well it seems to be what i thought i was doing ;) > and it also does the job on puppy and debian-live(lenny based) mmm.. TBH, I have no idea then :/ does it do the same if you copy the script in the home of your live system? Is it using programs in the script that are not in p:d ? ... a. --- [email protected] irc.goto10.org #pure:dyne
