sidux.com
sidux Requests - Important improvements
birdie - Jun 29, 2007 - 11:51 AM
Post subject: Important improvements
1) Include Terminus font and make default for Konsole
Explanation: Current font is antialiased thus Konsole window refreshes terribly slow in most cases. Also Terminus font has no license limitations and it's very pleasant for ones eyes
2) Include the following network utilities: arping, wireshark and tcpdump
Explanation: system administrators and experienced users often use Linux live CDs to resolve various network problems. And since the Internet is not always available we have no choice but to use another linux live CDs 
3) Optimize file allocation on CD so that CD/DVD drive spends less time seeking and more time reading contiguously (maybe it would be necessary to 'preread' some file during a boot sequence)
Is any explanation required?
slh - Jun 29, 2007 - 12:44 PM
Post subject: RE: Important improvements
I demand the bikeshed to be green.
DeepDayze - Jun 29, 2007 - 02:56 PM
Post subject: Re: RE: Important improvements
slh wrote:
I demand the bikeshed to be green.
Now THAT'S a real gem 
birdie - Jun 30, 2007 - 10:55 AM
Post subject:
I have recently discovered that sidux lacks smartctl utility ...
Please, include smartmontools as well.
JackieBrown - Jun 30, 2007 - 04:03 PM
Post subject:
Was slh too subtle?
Lanzi - Jun 30, 2007 - 04:11 PM
Post subject:
no
Scrooge - Jun 30, 2007 - 05:10 PM
Post subject:
Quote:
I demand the bikeshed to be green.
And moved 6 inches to the left.
h2 - Jun 30, 2007 - 05:29 PM
Post subject:
birdie, in case the above comments are too obscure, I'll answer:
1. User taste, not important, if you like it, install it. Possibly might get considered if there are no reasons not to do it.
2. Will not happen. Several reasons, german law now prohibits use of these types of tools, so sidux cannot put them on the livecd. That's the annoying reason, the other reason is that wireshark is simply too big to add, with dependencies it pulls in about 40 or 50 mB, I know, I asked the same thing, and checked. The livecd will not include those tools. If you need a sys admin specific livecd, then you are free to find one and use it, that's not a focus for sidux.
3. I assume this request is about as silly as it sounds. If you want fast performance with livecd, and if system has at least 3/4 gig ram, use toram option with lite version. Then it runs instantly.
kelmo - Jun 30, 2007 - 11:33 PM
Post subject:
h2 wrote:
3. I assume this request is about as silly as it sounds. If you want fast performance with livecd, and if system has at least 3/4 gig ram, use toram option with lite version. Then it runs instantly.
Not so silly, but simply requesting that we order the entire contents sequentially from "debian/sidux chroot" -> "squashfs" is easy. Writing the code to do it in an automated manner fit for our build scripts is not.
Therefore, much can be said about it, but without concept or code on how to achieve that, words are futile.
damentz - Jun 30, 2007 - 11:53 PM
Post subject:
They did it for the accelerated knoppix cd.
piper - Jul 01, 2007 - 12:25 AM
Post subject:
damentz wrote:
They did it for the accelerated knoppix cd.
"They" which is Alpha Systems Inc. and adopted as a "Project of Infrastructure Building for OpenSource-Software" by Information-Technology Promotion Agency, Japan and I believe uses LCAT, I could be wrong
kelmo - Jul 01, 2007 - 04:34 AM
Post subject:
I don't care what they did for accellerated knoppix, to be honest.
op4latino - Jul 01, 2007 - 05:09 AM
Post subject:
heh, I just learned a new proverb
slam - Jul 01, 2007 - 08:14 AM
Post subject:
Knoppix is built in a very different way sidux is. Actually it is always a manualy adapted and upgraded re-master of itself (By the way, Kanotix, too). If you manually (re-)master your build it is quite easy to do some file sorting (and bad hacks). As Knoppix comes as a huge packed DVD which is usually (and should be only!) used as a live CD there might be some reason to sort files on the disc.
sidux devs at the other side have created sophisticated build scripts which run fully automated and use the pure material from Debian Sid. This makes sidux 100% Debian compatible, and no hack will later on break your system with an upgrade. sidux is optimized to to be installed to HDD, the live functionality is well working but not the main focus.
With Tartaros I did some tests with interrupting the build process and do some manual file sorting. The resulting speed improvements at boot time where less than 2 seconds - so there is no reason to go further with this as sidux already boots extremely fast compared to other distros.
Greetings,
Chris
jaegermeister - Jul 01, 2007 - 08:41 PM
Post subject:
All this discussion suggests me that, should a sidux remaster tool be available, all the requests would cease, as people would be too busy to make it "their own way"
I did it manually some time ago, but an automated tool would be awesome!
BlueShadow - Jul 01, 2007 - 09:33 PM
Post subject:
Quote:
I did it manually some time ago, but an automated tool would be awesome!
That exists from beginning, you can use the original sidux build scripts.
http://svn.berlios.de/wsvn/fullstory/fl ... 0&sc=0
I wrote a tutorial in german (the bold warnings and disclaimer are important):
http://sidux.com/index.php?module=Wikul ... eCDMastern
Blue Shadow
jaegermeister - Jul 02, 2007 - 09:52 AM
Post subject:
Danke sehr for the tutorial, the described process is quite linear, so, when gaia comes out, I'll for sure give it a serious try.
Nonetheless, what I had in mind was an intelligent script that would handle everything, more or less the way SM script does: I have in my mind people, like one of my best friends to whom I've given a tartaros CD but knows nothing about linux, who need "to be taken by the hand".
These ones could benefit a lot from such automatisms!
Tschüß
devil - Jul 02, 2007 - 10:39 AM
Post subject:
why would you give a build script to someone that does not know linux at all?
the above script lacks even documentation so far, and as is pointed out in this unofficial wiki howto, underlies (sometimes) daily changes. i have to take a serious look at it sometimes to get the changes and have it working. its not meant to be spread at the moment.
greetz
devil
piper - Jul 02, 2007 - 08:57 PM
Post subject:
I agree, even some advanced users would have problems with this at some time or another ( daily changes, etc ... ) I also agree with (at the moment) that it is not meant to be spread.
jaegermeister - Jul 02, 2007 - 09:30 PM
Post subject:
In fact I'm talking about future, when the tool (and a reasonable UI) get mature 
piper - Jul 02, 2007 - 10:17 PM
Post subject:
I may be wrong, but, I highly doubt you will see a gui period (like I said, I could be wrong) to me it don't make sense to have one.
jaegermeister - Jul 02, 2007 - 11:13 PM
Post subject:
There's no specific need for a gui, in fact a text UI could be enough.
piper - Jul 02, 2007 - 11:18 PM
Post subject:
yakuake (cli) is best, works great as is
jaegermeister - Jul 02, 2007 - 11:25 PM
Post subject:
piper wrote:
yakuake (cli) is best, works great as is
Oh yes.... but sometimes crashes my beryl 0.2.0
Hope it'll be more behaving with Compiz Fusion
BlueShadow - Jul 02, 2007 - 11:30 PM
Post subject:
I think even a text UI is needless, because the build script is very easy to use and you should know what you are doing if you want to make a custom cd.
All that is needed for common use is a certain degree of stability (before that, the release dates are the best time to use the script) and a manpage.
But as slam said a few weeks ago in the german board, a gui would be nice, if somebody wants to code one.
kelmo - Jul 03, 2007 - 12:07 AM
Post subject:
Nope. If that happens i will never take responsibility for making changes that stuff up a user interface, nor do I plan to make an user interface.
Debian-Live project is planning these kind of things however.
piper - Jul 03, 2007 - 12:25 AM
Post subject:
kelmo wrote:
Nope. If that happens i will never take responsibility for making changes that stuff up a user interface, nor do I plan to make an user interface.
Debian-Live project is planning these kind of things however.
yakuake forever
tr0nic - Jul 05, 2007 - 12:30 PM
Post subject:
I have to agree that the fll-builder is only for advanced users. I tried it a few times but it never ran through due to some error message which I could not fix by editing the bash script ("cp: error: /boot/grub not a directory" - for those who are interested).
However, in the future, this could be a *great* tool, and could give sidux a "make-your-own-sidux" bonus which is something very special.
In fact, the only thing I'd need a (re)master for is the inclusion of iwlwifi-3945-ucode to have wireless up and running in live mode without editing sources etc. - especially if you don't have your USB stick with the ucode on it, or if you forgot your LAN cable, whatever
But for now, it's pretty unusuable for a standard user, and I agree that it shouldn't be spread atm. Every few weeks however, I'll give it a try - as I'm too curious and too impatient - but as I'm waiting, Gaia is coming nearer
wegface - Jul 08, 2007 - 08:00 AM
Post subject:
i had a butchers at dreamlinux the other day, that has a good, and easy remaster tool, works in a few clicks- very impressive.
jaegermeister - Jul 08, 2007 - 06:55 PM
Post subject:
Yes, impressive. It's more or less what I had in mind!
dzz - Jul 09, 2007 - 12:54 AM
Post subject:
For installation purposes sidux defaults are excellent as they are, we can apt-get any extras we need and tweak user settings later.
However for those of us who travel a lot, use different PC's but don't like most other OS's, a livecd with a few user-specific apps and settings is a very useful tool. Individual needs can never be met by the best defaults possible.
That script has been made available to download and a wiki page exists so it's certain to attract interest. But it's obviously not meant for general use (yet) because
Quote:
cp: error: /boot/grub not a directory
for me too and no man page so I did the "unclean remaster" just for a handful of needed extras and settings, fortunately it worked. I'm not interested in dreamlinux, pclinuxos or any other distro, I like sidux and proper debian.
I can't see the point of a master/remaster for other than a personal livecd nor a gui (those who can't run a script or have some reasonable Linux understanding are probably not up for that job at all), nor why anyone should expect official support.
But maybe this could be discussed more openly in the "anything goes" department. I wanted to write about this before but got the impression it's a "taboo" subject from the few posts in the German forum??
kelmo - Jul 09, 2007 - 01:14 AM
Post subject:
As one of the primary authors of the sidux tool I'll say it simply:
The tool that makes sidux is just that, a tool that makes sidux. It is not intended to make private copies of sidux, its intention is to be a tool that facilitates group collaboration to build a targeted set of products that we call "sidux".
There will be no support for anyone who does not want to achieve this goal, which means no support for anyone whose primary goal is to build a personalised "sidux".
Reason: simply don't have the time, nor am I personally interested or bothered to offer such a service. Others (like dreamlinux, debian-live) are.
Thanks, Kel.
wegface - Jul 09, 2007 - 08:47 AM
Post subject:
Quote:
Reason: simply don't have the time, nor am I personally interested or bothered to offer such a service. Others (like dreamlinux, debian-live) are.
kelmo: i agree exactly. Dreamlinux, slax etc actively encourage remastering and have spent long hours developing there tools to do this. sidux on the other hand has different core ideas. If one wants sidux, choose sidux. If one wants a custom distro, choose something else.
jaegermeister - Jul 09, 2007 - 11:09 AM
Post subject:
Personally I believe these two things have nothing against each other.
Plus, such a tool would only add competitive advantage to the distro.
Btw: if the point is just about "how time consuming" the project could be, an adaptation of tools created for other distros to the existing script could maybe cut times dramatically. I'm not doing it myself, just because I totally lack programming knowledge, but maybe somebody else could capitalize on the suggestion.
wegface - Jul 09, 2007 - 11:58 AM
Post subject:
jaegermeister: As far as i am aware at least, even back in kanotix days, anyone asking for help to remaster, has been given no support by any devs. Its just not on any of their wishlists. As its them with the programming knowledge, this isnt a feature thats gonna happen any time soon. Reasons for this (i think) are to stop a remaster which includes tons of non-free, maybe non-legal software being released by someone in a country where these laws are not valid. This could then directly compete with sidux, while doing nothing but stealing sidux's hard work. If its possible to remaster with a few clicks, or even a simple script, whats to stop someone or ANYONE doing this? Plus forums would be full of questions from people using non standard, non supported fake "sidux" installs. It opens many cans of worms.
N.B: this is just my 2 cents. This opinion may be completely different to sidux devs views.
jaegermeister - Jul 09, 2007 - 12:31 PM
Post subject:
This is in fact a true motivation for opposing the process.
Politics and not technical reasons.
Then, the next step of analysis, would be to examine whether such effects are actually happening to those distros who sport such tools or not.
etorix - Jul 09, 2007 - 04:22 PM
Post subject:
when i took up slackware, i used to make bootable dvds of ~current using one of pat's scripts, tho it was intended for cd
[on 56k .. it just took awhile to get fully updated]
but it didnt seem to me to be a "custom" slackware,it was just NORMAL
even tho it booted from, and installed, my own-kernel
sidux, however, is a different kettle of apples
if customise scripts aint supplied, by the free choice of the author, then deal with it
sidux is a live-cd install-platform for Debian sid
on-hd, its sid
locsmif - Jul 09, 2007 - 05:00 PM
Post subject:
I agree with kelmo's statement. I'd like to add this: I trust a distinction will be made between free(GPLv2/3) and supported.
The license the script(s) is(are) placed under encourages free distribution. But please don't be as bold as to ask support for a script, which you don't even understand; and which is used to create a distro which you intend to take from(remaster) but not necessarily give back to. That's where the support line in the sand is drawn, and I think that is fair.
regards, locsmif
slh - Jul 09, 2007 - 05:07 PM
Post subject:
sidux won't stop anything, compared to your prior experiences everything we use to build sidux is out in the open and licenced under FOSS licences (even though we often do not advertise this fact for the reasons noted below); however these tools can be dangerous in unexperienced hands and are under heavy development with major and unannounced changes several times a day (a single typo might lead to complete data loss of your host system). I'd like to stress clauses 11 and 12 of the GPL v2 (excuse me for the all-caps text, but that is copied verbatim from the GPL v2, as published by the FSF - emphasis mine):
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html wrote:
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
Creating an ISO image does require some basic knowledge about and good experience with UN*X and the SysV Bootprocess, no pretty GUI frontend can alleviate that. There are already more than enough badly crafted linux distributions around and we have neither the time nor the motivation to support customised "sidux" derived variants, besides that knowledge going into forks is usually lost for improving the base system. If you can cope with the existing framework, have your fun, but don't ask us for illustrated step-by-step guides or support for your custom creations. If you intend to distribute your customised creations, honor the licences (which are usually GPL2 compatible) and communicate to your potential users to contact you instead of the sidux project for support.
My personal target audience for fll-builder are not end users but team members and as such it will stay published, but unreleased code; if you want to change that, start coding to make it failsafe before even thinking about a GUI - my priorities are elsewhere.
The entry level to contribute code and patches to sidux itself isn't that high, show up on IRC and get in contact with us, communicate what you'd like to change and we'll usually try to review your proposal. Provided your suggestion meets the following requirements, we'll try our best to get your contributions into shape for a release:
- dfsg free/ legally redistributable in germany and the US
- meets our quality goals (we will support you in achieving that, yes it can take a while to achieve this)
- ongoing support is provided for the whole release cycle and seamless upgrades to future versions are possible (which means you take the responsibility to support it and stay in contact with us; high impact changes like switching the default window manager require 2 developers, lower impact feature additions can be maintained by one developer --> recent gnome discussions).
- communications are a primary requirement
- every addition comes with a space penalty for the release ISO, 703 MB are the hard limit and additions need to be justified. Re-using or interfacing (configurations) to packages already maintained by debian archive is preferred over custom code.
- have fun about it! After all this isn't a commercial entity but a volunteer project.
Basically it boils down to "show us the code and convince us why it's cool." You don't need to be a specialist - if you prefer it, you can also start to help us with janitorial tasks (take a look at our status reports for pending tasks, currently it is standardizing tools on ssft, gettext support and maintenance for bluetooth, gprs/ umts and modem/ isdn support) and learn about it while doing.
kelmo - Jul 09, 2007 - 10:37 PM
Post subject:
jaegermeister wrote:
This is in fact a true motivation for opposing the process.
Politics and not technical reasons.
Please retain some respect. I find your statement to be offensive.
Kel.
h2 - Jul 09, 2007 - 11:20 PM
Post subject:
Yes, I have to agree, the idea that some user, who isn't doing the work, isn't spending their free volunteer hours, can say that's because x or y factor, is absurd.
jaegermeister, the next step of the analysis is very simple: do you want to do the work to scratch your itch? That's what's simple, it's hard to be more clear than kelmo or slh are being.
Here's how it works in case it's unclear to you: you volunteer some of the finite amount of creative free time you have in life to do what you envision, as a developer. Maybe something isn't working, and it annoys you, so you fix it.
Maybe you create something you'd like to see exist because, well, because you'd like to see it exist.
So if a proposal or idea fails to meet this standard, that means nobody is going to be interested in spending any more of their free volunteer time on the idea. So at that point, the person who thought it was a good idea has 2 options: forget about it, or learn how to do what's needed themselves.
No one is obligated to do something like this thread is talking about, creating a fool proof mastering thing, that takes a lot of work and effort, and nobody gains at all. If someone feels that there is a gain, then they should start doing the work, since apparently this feeling isn't shared by developers.
Personally, while the latest work on the new livecd is definitely impressive, to me the point, in the end, is installing thing thing and using it. Live stuff is nice, it's cool, and it can be useful, but I don't think any project, except maybe knoppix, can really focus on that single thing long term and survive.
You need a large installed user base as far as I'm concerned, without that, there's no commitment to the community except in rare situations like cleary's use of livecd technology at his work, but then again, cleary puts a lot of testing and development time to get the stuff working in the first place.
I think you'll find that if you start programming, you'll soon see just why sometimes it's a lot easier writing a program for a single application than to try to make it stable enough for average users. For example, I'd estimate I need at least 10 times more code to make sm / sgfxi as fool proof and error resistant as I can, it's not trivial to do that, it's a huge amount of work, so unless you feel like doing that work, well, consider it a suggestion with no meaning since the desire for that functionality is not shared by others.
jaegermeister - Jul 10, 2007 - 12:45 AM
Post subject:
h2, I'd be totally happy to help the project by programming, the point is that I do not even know where to start from. The max I can do are trivial bash scripts to retrieve stuff from internet and start some make or other application.
This considered, I'm contributing to the community with bug reports, proposals and troubleshooting within this forum. So, in my spare time, I'm doing what I can, providing user contribution.
Then again, the issue of a customization tool is not a religion.... I have partially remastered tartaros myself without fll-builder (which I still haven't tried) following the online instructions. Instead, it's more about reflecting over a trend:
lately more and more distros are trying to give the user an advanced customizable experience, some through remaster ability (e.g. dreamlinux), others through an accurate choice of packages during install (http://www.go2linux.org/ultimate-ubuntu-edition-cd-1.4-gnarly-gnome). Not ignoring this trend would surely contribute in enlarging sidux user base. Linux is about freedom and customization, and today's users are even asking for further degrees of freedom.
locsmif - Jul 10, 2007 - 12:57 AM
Post subject:
Tutorials - very simple: http://linux.org.mt/article/terminal - simple: http://linuxcommand.org - advanced: http://www.tldp.org/LDP/abs/html
raft/rtfs, you'll have all the freedom you desire.
regards, locsmif
h2 - Jul 10, 2007 - 01:31 AM
Post subject:
Personally, I'd like to see sidux enlarge its user base by having more users run it as their primary operating system, installed. That's what I care about, that's what will make a difference long term re helping break the MS type monopolies that are holding back things.
Live stuff is nice for users, but for me it's never been an emphasis, I like having the livecd, and since I can use it to install anything easily, that's fine with me, but the important thing is to get people running any free desktop, for real, installed. Nothing else will achieve the result of cracking the MS / proprietary desktop near monopoly.
Users who really run sidux installed are far more likely I think as a group to contribute help and support long term, since it's their actual system they are running, not a relatively static livecd thing. One reason I really like what kelmo and everyone have done with the new livecd is that it's very much like installed now, so it's easy for users to get a feel for it by actually running it, at which point hopefully they will proceed and install the thing for real.
If you're thinking in terms of expansion, then don't think small, livecd users are a tiny fraction of installed users, so installed is the logical place to focus as far as I'm concerned, that's what I do anyway. Having maintainable livecd stuff is important long term, it's the way sidux will continue to exist, but it goes no further than that, my point is that it's a LOT harder to make a script that works for a small group of focused people work for a large group of relatively unskilled people, and sidux doesn't gain anything by doing that.
There are millions of computers out there waiting to run free desktops, ideally debian, why worry about a tiny number of specialized users?
jamesstilwell3rd - Nov 22, 2007 - 08:55 AM
Post subject:
I believe I understand why the core sidux crew does not want to spend time on a gee-whiz gui to remaster (and usually break) a system that works quite well as is. I also agree that primarily live distros are never going to put a serious dent in MS market share. Community development requires some user commitment to make it work well.
All that being said, a good solid tutorial would be nice when comes time to insert my wireless firmware, kismet, wireshark, etc (all the stuff I would not ask the maintainers to do for me) into my SiduxUSB.img. I'm not asking for a script, only some sidux specific docs on how to do these things. If this already exists, point me please.
slam - Nov 22, 2007 - 10:15 AM
Post subject:
jaegermeister wrote:
This is in fact a true motivation for opposing the process.
Politics and not technical reasons.
Haha, what a funny conspiracy theory! While in former Kanotix days there might have been commercial reasons for not supporting re-masters, we at sidux do not have these reasons at all.
Actually the sidux team has already supported several special builds (for special language support, for special use in schools, for DVD distribution in IT-magazines, ....). Besides several non-coders have picked the sidux build scripts and successfully used for personal mastering. They all did that without a manual, HowTo or GUI - just by reading the (extensive and clear!) inline documentation in the scripts.
Meanwhile several sidux core developers have answered here (in a very open, friendly and helpful tone, by the way), please understand that sidux of course wants to be spread all around the world. After all our final goal is world domination, right?
However, we want to spread based on the quality level we all demanded from the very beginning. And I am talking about just about code quality, but also support quality. So, please get involved as slh and others have invited you already several times.
Greetings,
Chris
jamesstilwell3rd - Nov 22, 2007 - 07:30 PM
Post subject: dev philosophy
It doesn't matter whether their reasons are practical or philosophical, the devs doing the heavy lifting are entitled to make decisions regarding the direction of their distro. The user market will decide whose philosophy and work they agree with most and vote with their hard drives.
Question for Slam:
The following NEW packages will be installed:
fll-live-initscripts
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
Need to get 0B/48.6kB of archives.
After unpacking 250kB of additional disk space will be used.
(Reading database ... 207480 files and directories currently installed.)
Unpacking fll-live-initscripts (from .../fll-live-initscripts_2.0.61_all.deb) ...
############################################################
Installing this package is dangerous and not supported!
Aborting installation.
############################################################
dpkg: error processing /var/cache/apt/archives/fll-live-initscripts_2.0.61_all.deb (--unpack):
subprocess pre-installation script returned error exit status 1
Errors were encountered while processing:
/var/cache/apt/archives/fll-live-initscripts_2.0.61_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Are the fll scripts are the ones I need to look at for customization? If this question needs to posted somewhere else, I'd be glad to do so.
Maybe I'm completely on the wrong track. Thank you.
Also, I run a K12LTSP based system for a small private school on a voluntary basis. Where can I get a peek at that educationally oriented remaster?
slam - Nov 22, 2007 - 09:12 PM
Post subject: RE: dev philosophy
The build scripts are here http://svn.berlios.de/wsvn/fullstory/fl ... 0&sc=0 - and the community doing sidux-edu is here https://noc.sidux.com/projects/edu
Greetings,
Chris
piper - Nov 22, 2007 - 09:17 PM
Post subject: RE: dev philosophy
I think people are getting building and remastering very confused, my 2 ¢
jamesstilwell3rd - Nov 22, 2007 - 09:35 PM
Post subject: Thanks for the info.
Thank you for the links slam.
To Piper:
It's not that I'm confused about the difference between building and remastering, only that need to do both yet know very little about either. I'm warming up my google:foo now that I've got a place to start. Thanks again all for guidance.
All times are GMT - 12 Hours
Powered by
PNphpBB2 © 2003-2009 The Zafenio Group
Credits