vectorlinux-devel — Vector Linux developer's list

Re: [Vectorlinux-devel] Packaging Standards Redux

[Jose J. R. <jo...@gm...>]

On 4/8/06, joh...@gm... <joh...@gm...> wrote:
> Some programs create their configuration files in an etc directory. I hav=
e
> seen some packages where such an etc directory was a subdirectory under /=
usr
> or /usr/X11R6. Since we are discussing standards for building packages wi=
th
> VL6, I believe that one of the arguments that should be passed to just ab=
out
> all configure scripts is --sysconfdir=3D/etc as opposed to letting the
> sysconfdir setting default to a sub under --prefix=3D/usr.
>
> While I'm on this thread, some programs also create local data, notably d=
bus,
> hal, and samba, among others. I want to propose that we explicitly pass
> --localstatedir=3D/var to the configure script for such programs where lo=
cal
> state data is created.
>
> Thoughts on these ideas, please.
>

I agree on /var, since this is sometimes mounted on a separate
partition even. On /etc, I had my misgivings at first, thinking that
programs that install to /usr should use /usr/etc; but after careful
thought and checking out /usr/local/etc (found it empty), /usr/etc
(only sane.d, printcap and wgetrc) and /opt/kde/etc (only xdg and
ksysguarddrc), I realised that, at least the apps I've packaged, and
also any others I've installed, use /etc anyway. It has the added
advantage of making it easier to backup such info.

Regards,
Joe1962

Re: [Vectorlinux-devel] Packaging Standards Redux

[John B <joh...@gm...>]

Guys,

The Tukaani pkgtools will allow us to build most packages as non-root users=
.
It passes --group=3Droot and --owner=3Droot to tar-1.13. Here are a couple =
of
links from the tukaani.org website:

ftp://tukaani.org/tukaani/tukaani-edge/source/tools/README - this file
explains how the tukaani tools work.

ftp://tukaani.org/tukaani/tukaani-edge/source/tools - it would be worth
checking out both the fakedestdir and tukbuild scripts. The fakedestdir
script will allow us to execute make install to a staging directory for
programs where make install DESTDIR=3D is not supported (unfortunately, the=
re
are enough of those around).

The tukbuild script is an interesting alternative to checkinstall and one
I've studied for a little bit. It appears to take the elements of
traditional SlackBuild scripts and standardizes a lot of build locations,
among other things, like including the stripping of unnecessary symbols fro=
m
the executables and shared libraries. (I like the standardization of instal=
l
locations in the tukbuild script - we could always modify it for our needs
as far as install locations go.) The way tukbuild works is you have a
program.tukbuild file. You invoke tukbuild and pass to it the
program.tukbuild file as a regular user. The tukbuild script then goes to
work based on the info in the program.tukbuild file. The tukbuild script
appears to be pretty well-commented so that even somebody with a limited
grasp of scripting, like me, can understand what is supposed to happen.

Below is the amarok.TukBuild file text to give you an idea of how this
system works, with my comments interspersed:

# set initial variables
NAME=3Damarok
VERSION=3D1.3.9
SOURCE=3Dhttp://dl.sf.net/amarok/amarok-$VERSION.tar.bz2 <--allows source t=
o
be downloaded if not already on box
BUILD=3D${BUILD:-1} <---set the build version; for us it would be #vl5 of #=
vl6
for the new version
# Trying to make it more stable, unsure if helps:
OPTIMIZE=3D${OPTIMIZE:-"-O1 -pipe"} <---FWIW, I've been able to build amaro=
k
with -O2, but then what do I know? ;-)
PREFIXTYPE=3Dkde <--- this macro tells the tukbuild script that we are
building a kde app and to use kde defaults

build() {
    _explode 0 <---this macro causes the tukbuild script to decompress the
tarball into a build directory
    cd amarok-$VERSION
    $CONFIGURE \ <---this macro invokes the ./configure script based on the
BUILD, OPTIMIZE and PREFIXTYPE set above - it also allows
application-specific settings to be passed, like the ones below
        --disable-debug \
        --disable-mysql \
        --enable-amazon \
        --without-gstreamer \
        --without-xmms
    make -j$MAKEJOBS <---the $MAKEJOBS variable is set in the main tukbuild
script based on the
    make DESTDIR=3D"$PKG" install
    _doc_except 0 amarok-$VERSION <---this macro creates the documentation
directory
    _chfix <---this macro will set the permissions to 0755 for executables
and 0644 for non-executables
    _chgrp_bin <---this macro will the owner and group for the executables
and directories to root.bin. Of course we could choose not to use it, since
I think it makes more sense for root.root to own the apps. ;-)
}

The tukbuild system may or may not be useful to us, but as I mentioned
above, I do like the fact that once you specify what type of building you'r=
e
doing, default locations are imposed (aka standards).

I hope y'all find this response useful.

Best,
John



On 4/8/06, Tony Brijeski <tb...@gm...> wrote:
>
> I agree with John and having standards.
>
> Ram - I don't think we should start allowing package installs all over th=
e
> place. This is asking for a huge headache.
>
>
>
> On 4/8/06, Sriram Durbha <sri...@gm...> wrote:
> >
> > you are right on the target john.it is much easier to support if we kno=
w
> > where all the files are going to be installed. and much better if they =
are
> > in a standard place for al packages.
> >
> > On a related note..  Most of the time i install to a local directory.  =
i
> > hate to pollute the root .
> > especially because it becomes difficult to uninstall if the package
> > doesnt have a good uninstall rule in the make file.
> >
> > One thing we can do to simplify things is allow installpkg to be run as
> > non root user also.
> >
> > If we are going to go the length,   shall we as well ask the user a
> > question like
> > " Install for all users or install for current user only ?" and proceed
> > appropriately to install in the user's $HOME or /
> >
> > The tree for the packge remains the sme but is located differently.
> > the local log of packages like in /var/log/packages .. will also have a
> > corresponding local version in $HOME
> >
> > To help this
> > we could have a list of packages and their options ..  something like
> > this ..
> > http://numsum.com/spreadsheet/show/17688
> > and create the ./configue  commands from that for all the packages for
> > the default install.
> >
> > cheers
> > ram
> >
> >
> >
> >
> > On 4/7/06, joh...@gm... < joh...@gm...> wrote:
> > >
> > > Some programs create their configuration files in an etc directory. I
> > > have
> > > seen some packages where such an etc directory was a subdirectory
> > > under /usr
> > > or /usr/X11R6. Since we are discussing standards for building package=
s
> > > with
> > > VL6, I believe that one of the arguments that should be passed to jus=
t
> > > about
> > > all configure scripts is --sysconfdir=3D/etc as opposed to letting th=
e
> > > sysconfdir setting default to a sub under --prefix=3D/usr.
> > >
> > > While I'm on this thread, some programs also create local data,
> > > notably dbus,
> > > hal, and samba, among others. I want to propose that we explicitly
> > > pass
> > > --localstatedir=3D/var to the configure script for such programs wher=
e
> > > local
> > > state data is created.
> > >
> > > Thoughts on these ideas, please.
> > >
> > > Thanks,
> > > John
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > > language
> > > that extends applications into web and mobile media. Attend the live
> > > webcast
> > > and join the prime developer group breaking into this new coding
> > > territory!
> > > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&d=
at=3D121642
> > >
> > > _______________________________________________
> > > Vectorlinux-devel mailing list
> > > Vec...@li...
> > > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
> > >
> >
> >
>

Re: [Vectorlinux-devel] Packaging Standards Redux

[Tony B. <tb...@gm...>]

I agree with John and having standards.

Ram - I don't think we should start allowing package installs all over the
place. This is asking for a huge headache.


On 4/8/06, Sriram Durbha <sri...@gm...> wrote:
>
> you are right on the target john.it is much easier to support if we know
> where all the files are going to be installed. and much better if they ar=
e
> in a standard place for al packages.
>
> On a related note..  Most of the time i install to a local directory.  i
> hate to pollute the root .
> especially because it becomes difficult to uninstall if the package doesn=
t
> have a good uninstall rule in the make file.
>
> One thing we can do to simplify things is allow installpkg to be run as
> non root user also.
>
> If we are going to go the length,   shall we as well ask the user a
> question like
> " Install for all users or install for current user only ?" and proceed
> appropriately to install in the user's $HOME or /
>
> The tree for the packge remains the sme but is located differently.
> the local log of packages like in /var/log/packages .. will also have a
> corresponding local version in $HOME
>
> To help this
> we could have a list of packages and their options ..  something like thi=
s
> ..
> http://numsum.com/spreadsheet/show/17688
> and create the ./configue  commands from that for all the packages for th=
e
> default install.
>
> cheers
> ram
>
>
>
>
> On 4/7/06, joh...@gm... <joh...@gm...> wrote:
> >
> > Some programs create their configuration files in an etc directory. I
> > have
> > seen some packages where such an etc directory was a subdirectory under
> > /usr
> > or /usr/X11R6. Since we are discussing standards for building packages
> > with
> > VL6, I believe that one of the arguments that should be passed to just
> > about
> > all configure scripts is --sysconfdir=3D/etc as opposed to letting the
> > sysconfdir setting default to a sub under --prefix=3D/usr.
> >
> > While I'm on this thread, some programs also create local data, notably
> > dbus,
> > hal, and samba, among others. I want to propose that we explicitly pass
> > --localstatedir=3D/var to the configure script for such programs where
> > local
> > state data is created.
> >
> > Thoughts on these ideas, please.
> >
> > Thanks,
> > John
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking scripting
> > language
> > that extends applications into web and mobile media. Attend the live
> > webcast
> > and join the prime developer group breaking into this new coding
> > territory!
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> > _______________________________________________
> > Vectorlinux-devel mailing list
> > Vec...@li...
> > https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
> >
>
>

Re: [Vectorlinux-devel] Packaging Standards Redux

[Sriram D. <sri...@gm...>]

you are right on the target john.it is much easier to support if we know
where all the files are going to be installed. and much better if they are
in a standard place for al packages.

On a related note..  Most of the time i install to a local directory.  i
hate to pollute the root .
especially because it becomes difficult to uninstall if the package doesnt
have a good uninstall rule in the make file.

One thing we can do to simplify things is allow installpkg to be run as non
root user also.

If we are going to go the length,   shall we as well ask the user a questio=
n
like
" Install for all users or install for current user only ?" and proceed
appropriately to install in the user's $HOME or /

The tree for the packge remains the sme but is located differently.
the local log of packages like in /var/log/packages .. will also have a
corresponding local version in $HOME

To help this
we could have a list of packages and their options ..  something like this
..
http://numsum.com/spreadsheet/show/17688
and create the ./configue  commands from that for all the packages for the
default install.

cheers
ram



On 4/7/06, joh...@gm... <joh...@gm...> wrote:
>
> Some programs create their configuration files in an etc directory. I hav=
e
> seen some packages where such an etc directory was a subdirectory under
> /usr
> or /usr/X11R6. Since we are discussing standards for building packages
> with
> VL6, I believe that one of the arguments that should be passed to just
> about
> all configure scripts is --sysconfdir=3D/etc as opposed to letting the
> sysconfdir setting default to a sub under --prefix=3D/usr.
>
> While I'm on this thread, some programs also create local data, notably
> dbus,
> hal, and samba, among others. I want to propose that we explicitly pass
> --localstatedir=3D/var to the configure script for such programs where lo=
cal
> state data is created.
>
> Thoughts on these ideas, please.
>
> Thanks,
> John
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Vectorlinux-devel mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
>

[Vectorlinux-devel] Packaging Standards Redux

[<joh...@gm...>]

Some programs create their configuration files in an etc directory. I have 
seen some packages where such an etc directory was a subdirectory under /usr 
or /usr/X11R6. Since we are discussing standards for building packages with 
VL6, I believe that one of the arguments that should be passed to just about 
all configure scripts is --sysconfdir=/etc as opposed to letting the 
sysconfdir setting default to a sub under --prefix=/usr.

While I'm on this thread, some programs also create local data, notably dbus, 
hal, and samba, among others. I want to propose that we explicitly pass 
--localstatedir=/var to the configure script for such programs where local 
state data is created.

Thoughts on these ideas, please.

Thanks,
John

[Vectorlinux-devel] Re: Slack Builds and VL - my suggestions

[Tony B. <tb...@gm...>]

I agree that std and soho should be separate and should have separate
repos and I thought I made that clear in my original message - lol.

Live would be Uel's baby so I'll let him address that.  As part of his
live build, he could just strip out the dev stuff but then installing
that would be a pain since you couldn't make packages without having
to download everything.  Folks that need ati or nvidia drivers or any
other proprietary drivers would be SOL.


On 4/6/06, Sriram Durbha <sri...@gm...> wrote:
> hi, am sorry i could not be part of the irc conversation. But may i sugge=
st
> that we should consider the live versions also from the start?
> the key would be to start with a really simple base.
> here is the layout i have in mind[ very awkward.. but might work.. change=
s
> invited :) ]
>
> 1. Dev base
> 2. Non Dev base [ for the minimal live CD ]
> 3. Std [ 1 +  no kde - soho apps ]
> 4. SOHO [ 1 +  kde + soho apps ]
> 5. Std Live [ 2 + * ]
> 6. SOHO Live [ 2 +  kde + soho apps ]
>
> i agree that our primary objective for SoHo should be kde only. if there =
is
> a lot of demand for other WMs, that should be an additional package.
> what we release should be usable .. for example puppy linux uses VL as th=
eir
> host development system.   But their install is simple and clean.  We can=
 do
> a similar thing.
>
> commonly pooping up themes :
> 1. upgrade path from std to soho
> 2. --dist_upgrade
>
> If we ignore one 1. have two clearly demarcated repos for std and soho . =
2.
> is possible
>
> And it makes development and package management a lot easier if we consid=
er
> them two seperate Distros altogether.. they share only the vector
> philosophy.. and the non KDE part of the initial base system.  All packag=
es
> that can take advantage of having KDE as a dep should  have it .
>
> Life will be much much easier for ever one involved, devs, pkgers and use=
rs
> :)
> cheers
> ram
>
>
>
>
>
> On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
> >
> >
> >
> > On 4/6/06, uel archuletta <ue...@gm...> wrote:
> >
> > >
> > >
> > >  On 4/6/06, Tony Brijeski < tb...@gm...> wrote:
> > > >
> > > >
> > > >
> > > >  On 4/6/06, uel archuletta < ue...@gm...> wrote:
> > > >
> > > > > Sounds good. I have some additions to a few of your propositions.
> > > > > here thay are
> > > > >
> > > > > 1. we have some package list we may be able to use to help in thi=
s
> > > > > they are in ftp in the VL6base folder.
> > > > > 2. I nominate you to build the base and get it setup for us. :)
> > > > >
> > > >
> > > >  OK
> > > >
> > > >
> > > >  3. sounds good, but do we have enough people to seperate into 2
> > > > > groups?
> > > > >
> > > >
> > > >  If not 2 groups, then each dev can have 2 partitions for dev - std
> > > > and soho. This shouldn't be too bad a task if we have all the pkgs
> decided
> > > > upon at the beginning and hand out the workload equally. Remember, =
in
> the
> > > > past Robert did std by himself and I did soho by myself on top of s=
td
> so it
> > > > is possible.
> > > >
> > >
> > > That is workable 2 seperate workloads if one has time/space they coul=
d
> > > work on both.
> > >
> > >
> > >
> > >   4. agree
> > > > > 5. agree
> > > > > 6. I along with others would like to see this borken down further=
.
> > > > > base-cli, dev, X, std, soho, some examples would be the package
> lists in
> > > > > VL6base on ftp.
> > > > >
> > > >
> > > >
> > > >  base-cli and dev will have to be 1 since we can't work on a base
> > > > without dev tools.
> > > >
> > >
> > > this is where I get things mixed up so correct me if I am wrong. if w=
e
> > > are building packages and populating a repo then we can build a base =
for
> the
> > > devs to build packages on that has all tools and X, and then build a
> base
> > > for the installer that has them seperated out. as long as we test the
> > > packages on this base as well.
> > >
> >
> >
> > I think this would create more work.  Apps built for SOHO would have
> > kde-centric additions wherever possible to integrate them better into t=
he
> > desktop environment. While we may use the same apps for std, they shoul=
d
> not
> > have kde deps in them.  This is kind of like the issue you get if you t=
ry
> to
> > install packages from linuxpackages.net - arts has a dep of gnome - wtf=
?
> > Whay would you build arts with a gnome dep. Same goes for apps for std
> that
> > might have a kde dep - not a good thing at all.
> >
> > The base would be common to all, including X and dev.  std(WM's and
> > apps) and soho(KDE and apps) would then be built on top of the base.  S=
oho
> > would have KDE as its first build so that any other app installs after
> that
> > would be able to use kde hooks where needed.
> >
> >
> >
> > >
> > >
> > >   X - if by this you mean xorg alone then I agree but if this include=
s
> > > > WM's,etc then no.
> > > >
> > >
> > > Vec asked if we couldnt include xfce in our xorg package since it is =
in
> > > both, and if we go down to the package level it woould simply mean
> adding it
> > > to the metapackage
> > >
> > >
> >
> >
> > I really don't think xfce should be in SOHO.  IMHO, 99% of those that g=
et
> > SOHO are getting it for kde and not xfce.  If they want xfce, they shou=
ld
> > stick with std.  This would also allow us to make soho easier and bette=
r
> due
> > to the fact that you wouldn't have to worry about menus and such as lon=
g
> as
> > a kde .desktop file was included with the packages.
> > Folks that are looking for xfce aren't looking for the bloat of kde and
> > those looking for the richness and integration of kde aren't looking fo=
r
> > xfce.  Again, we need to go back and look at the target market for thes=
e
> and
> > not what we want out of it.  We could always add wm's and such to the r=
epo
> > but I doubt they'd get a lot of hits.
> >
> > Concentrating only on kde for soho would be the best bet.  choosing app=
s
> > for soho should also be centred around kde as well so they integrate
> > properly into the DE.  The maturity of the apps for kde is there now an=
d
> we
> > should take advantage of that.
> >
> > The only folks I know that run SOHO with xfce are vec and monty - lol. =
No
> > offense guys.
> >
> > We need to focus on packages as that is what is really important. That =
is
> > why stuff like ubuntu, gentoo,etc have gained the popularity they have.
> > Folks don't have to go searching a million different places to get what
> they
> > need. It is all available from a central source for the most part.
> >
> > Linuxpackages and slacky.it are ok but they still have some goofyness t=
o
> > them with deps of stuff that isn't needed.
> >
> >
> >
> > >    7. I think there should be a seperation in release dates. 1 reason=
 is
> > > > > Distrowatch another is easier for us to debug.
> > > > > 8.agree
> > > > > 9.agree
> > > > > 10.agree
> > > > > 11. see #7
> > > > > 12. I really like this idea
> > > > > 13. agree
> > > > > 14. agree
> > > > >
> > > > > some really good ideas here Tony.
> > > > > Thanks,
> > > > >
> > > > > Uel
> > > > >
> > > > >
> > > > > On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> > > > > >
> > > > > >  Sorry if this has already been decided upon but I haven't been
> > > > > > made aware of it so here goes.
> > > > > >
> > > > > > I have been looking at these as I'm sure some or all of you hav=
e
> > > > > > as well.
> > > > > >
> > > > > > I think we can work with these to build our base from source an=
d
> > > > > > then expand on them in the future.
> > > > > >
> > > > > > There were a few of us on irc last night chatting about it.
> > > > > >
> > > > > > This is how I think we should move forward with this:
> > > > > >
> > > > > > 1 - as a group, decide on all the packages for both std vl and
> > > > > > soho before we start
> > > > > > 2 - 1 person designated to build the bare minimum base(a/ap/d/l=
/k
> > > > > > source trees) - probably either myself or Uel or anyone that wa=
nts
> to take
> > > > > > ownership of this task - all base build scripts need to be
> corrected for
> > > > > > arch,flags,etc
> > > > > > 3 - once the base is built, each developer is given a source tr=
ee
> > > > > > or trees and they work on those on top of the base(vlbase.tgz).=
eg.
> > > > > > kde,xap,etc - all packages must be built on a virgin base excep=
t
> for soho -
> > > > > > 2 groups are needed here - std and soho and there will be some
> duplication
> > > > > > as std and soho should be treated as separate distros - all bui=
ld
> scripts
> > > > > > need to corrected for arch,flags,etc
> > > > > > 4 - we need to come up with SlackBuilds for the packages we
> > > > > > include that aren't in slack and split this up depending on how
> many pkgs
> > > > > > there are
> > > > > > 5 - upload all the built packages to the respective trees and e=
ach
> > > > > > of us install them for testing.
> > > > > > 6 - once testing is completed, we package these up for the cd i=
nto
> > > > > > vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related
> > > > > > packages should reside in vl-std.tgz and vl-soho.tgz so that SO=
HO
> > > > > > can be KDE only and have all packages built for it using kde as=
 a
> dep.
> > > > > > 7 - release beta std and soho at the same time
> > > > > > 8 - set a beta test schedule of 2 weeks
> > > > > > 9 - fix and release rc
> > > > > > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 unt=
il
> > > > > > stable.
> > > > > > 11 - release final std and soho at the same time.
> > > > > > 12 - designate a dev for each versions - std and soho - whose
> > > > > > primary responsibility will be security patching
> > > > > > 13 - start working on extra packages for the repo
> > > > > > 14 - once there is a large repo of apps available, start the ne=
xt
> > > > > > cycle at step 1
> > > > > >
> > > > > > Let me know what you all think.  Having this process more
> > > > > > organized and coordinated will allow us to work quicker and mor=
e
> efficiently
> > > > > > giving us more time to create the extra app repo that is needed=
 to
> take VL
> > > > > > to the next level. That way when Robert becomes rich from VL, h=
e
> will share
> > > > > > with all of us - lol.
> > > > > >
> > > > > > Regards,
> > > > > >  Tony
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
>
>

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[Sriram D. <sri...@gm...>]

hi, am sorry i could not be part of the irc conversation. But may i suggest
that we should consider the live versions also from the start?
the key would be to start with a really simple base.
here is the layout i have in mind[ very awkward.. but might work.. changes
invited :) ]

1. Dev base
2. Non Dev base [ for the minimal live CD ]
3. Std [ 1 +  no kde - soho apps ]
4. SOHO [ 1 +  kde + soho apps ]
5. Std Live [ 2 + * ]
6. SOHO Live [ 2 +  kde + soho apps ]

i agree that our primary objective for SoHo should be kde only. if there is
a lot of demand for other WMs, that should be an additional package.
what we release should be usable .. for example puppy linux uses VL as thei=
r
host development system.   But their install is simple and clean.  We can d=
o
a similar thing.

commonly pooping up themes :
1. upgrade path from std to soho
2. --dist_upgrade

If we ignore one 1. have two clearly demarcated repos for std and soho . 2.
is possible

And it makes development and package management a lot easier if we consider
them two seperate Distros altogether.. they share only the vector
philosophy.. and the non KDE part of the initial base system.  All packages
that can take advantage of having KDE as a dep should  have it .

Life will be much much easier for ever one involved, devs, pkgers and users
:)
cheers
ram





On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
>
>
>
> On 4/6/06, uel archuletta <ue...@gm...> wrote:
>
> >
> >
> >  On 4/6/06, Tony Brijeski < tb...@gm...> wrote:
> > >
> > >
> > >
> > >  On 4/6/06, uel archuletta < ue...@gm...> wrote:
> > >
> > > > Sounds good. I have some additions to a few of your propositions.
> > > > here thay are
> > > >
> > > > 1. we have some package list we may be able to use to help in this
> > > > they are in ftp in the VL6base folder.
> > > > 2. I nominate you to build the base and get it setup for us. :)
> > > >
> > >
> > >  OK
> > >
> > >
> > >  3. sounds good, but do we have enough people to seperate into 2
> > > > groups?
> > > >
> > >
> > >  If not 2 groups, then each dev can have 2 partitions for dev - std
> > > and soho. This shouldn't be too bad a task if we have all the pkgs de=
cided
> > > upon at the beginning and hand out the workload equally. Remember, in=
 the
> > > past Robert did std by himself and I did soho by myself on top of std=
 so it
> > > is possible.
> > >
> >
> > That is workable 2 seperate workloads if one has time/space they could
> > work on both.
> >
> >
> >
> >   4. agree
> > > > 5. agree
> > > > 6. I along with others would like to see this borken down further.
> > > > base-cli, dev, X, std, soho, some examples would be the package lis=
ts in
> > > > VL6base on ftp.
> > > >
> > >
> > >
> > >  base-cli and dev will have to be 1 since we can't work on a base
> > > without dev tools.
> > >
> >
> > this is where I get things mixed up so correct me if I am wrong. if we
> > are building packages and populating a repo then we can build a base fo=
r the
> > devs to build packages on that has all tools and X, and then build a ba=
se
> > for the installer that has them seperated out. as long as we test the
> > packages on this base as well.
> >
>
>
> I think this would create more work.  Apps built for SOHO would have
> kde-centric additions wherever possible to integrate them better into the
> desktop environment. While we may use the same apps for std, they should =
not
> have kde deps in them.  This is kind of like the issue you get if you try=
 to
> install packages from linuxpackages.net - arts has a dep of gnome - wtf?
> Whay would you build arts with a gnome dep. Same goes for apps for std th=
at
> might have a kde dep - not a good thing at all.
>
> The base would be common to all, including X and dev.  std(WM's and
> apps) and soho(KDE and apps) would then be built on top of the base.  Soh=
o
> would have KDE as its first build so that any other app installs after th=
at
> would be able to use kde hooks where needed.
>
>
>
> >
> >
> >   X - if by this you mean xorg alone then I agree but if this includes
> > > WM's,etc then no.
> > >
> >
> > Vec asked if we couldnt include xfce in our xorg package since it is in
> > both, and if we go down to the package level it woould simply mean addi=
ng it
> > to the metapackage
> >
> >
>
>
> I really don't think xfce should be in SOHO.  IMHO, 99% of those that get
> SOHO are getting it for kde and not xfce.  If they want xfce, they should
> stick with std.  This would also allow us to make soho easier and better =
due
> to the fact that you wouldn't have to worry about menus and such as long =
as
> a kde .desktop file was included with the packages.
> Folks that are looking for xfce aren't looking for the bloat of kde and
> those looking for the richness and integration of kde aren't looking for
> xfce.  Again, we need to go back and look at the target market for these =
and
> not what we want out of it.  We could always add wm's and such to the rep=
o
> but I doubt they'd get a lot of hits.
>
> Concentrating only on kde for soho would be the best bet.  choosing apps
> for soho should also be centred around kde as well so they integrate
> properly into the DE.  The maturity of the apps for kde is there now and =
we
> should take advantage of that.
>
> The only folks I know that run SOHO with xfce are vec and monty - lol. No
> offense guys.
>
> We need to focus on packages as that is what is really important. That is
> why stuff like ubuntu, gentoo,etc have gained the popularity they have.
> Folks don't have to go searching a million different places to get what t=
hey
> need. It is all available from a central source for the most part.
>
> Linuxpackages and slacky.it are ok but they still have some goofyness to
> them with deps of stuff that isn't needed.
>
>
>
> >    7. I think there should be a seperation in release dates. 1 reason i=
s
> > > > Distrowatch another is easier for us to debug.
> > > > 8.agree
> > > > 9.agree
> > > > 10.agree
> > > > 11. see #7
> > > > 12. I really like this idea
> > > > 13. agree
> > > > 14. agree
> > > >
> > > > some really good ideas here Tony.
> > > > Thanks,
> > > >
> > > > Uel
> > > >
> > > >
> > > > On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> > > > >
> > > > >  Sorry if this has already been decided upon but I haven't been
> > > > > made aware of it so here goes.
> > > > >
> > > > > I have been looking at these as I'm sure some or all of you have
> > > > > as well.
> > > > >
> > > > > I think we can work with these to build our base from source and
> > > > > then expand on them in the future.
> > > > >
> > > > > There were a few of us on irc last night chatting about it.
> > > > >
> > > > > This is how I think we should move forward with this:
> > > > >
> > > > > 1 - as a group, decide on all the packages for both std vl and
> > > > > soho before we start
> > > > > 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k
> > > > > source trees) - probably either myself or Uel or anyone that want=
s to take
> > > > > ownership of this task - all base build scripts need to be correc=
ted for
> > > > > arch,flags,etc
> > > > > 3 - once the base is built, each developer is given a source tree
> > > > > or trees and they work on those on top of the base(vlbase.tgz).eg=
.
> > > > > kde,xap,etc - all packages must be built on a virgin base except =
for soho -
> > > > > 2 groups are needed here - std and soho and there will be some du=
plication
> > > > > as std and soho should be treated as separate distros - all build=
 scripts
> > > > > need to corrected for arch,flags,etc
> > > > > 4 - we need to come up with SlackBuilds for the packages we
> > > > > include that aren't in slack and split this up depending on how m=
any pkgs
> > > > > there are
> > > > > 5 - upload all the built packages to the respective trees and eac=
h
> > > > > of us install them for testing.
> > > > > 6 - once testing is completed, we package these up for the cd int=
o
> > > > > vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related
> > > > > packages should reside in vl-std.tgz and vl-soho.tgz so that SOHO
> > > > > can be KDE only and have all packages built for it using kde as a=
 dep.
> > > > > 7 - release beta std and soho at the same time
> > > > > 8 - set a beta test schedule of 2 weeks
> > > > > 9 - fix and release rc
> > > > > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until
> > > > > stable.
> > > > > 11 - release final std and soho at the same time.
> > > > > 12 - designate a dev for each versions - std and soho - whose
> > > > > primary responsibility will be security patching
> > > > > 13 - start working on extra packages for the repo
> > > > > 14 - once there is a large repo of apps available, start the next
> > > > > cycle at step 1
> > > > >
> > > > > Let me know what you all think.  Having this process more
> > > > > organized and coordinated will allow us to work quicker and more =
efficiently
> > > > > giving us more time to create the extra app repo that is needed t=
o take VL
> > > > > to the next level. That way when Robert becomes rich from VL, he =
will share
> > > > > with all of us - lol.
> > > > >
> > > > > Regards,
> > > > >  Tony
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[Tony B. <tb...@gm...>]

On 4/6/06, uel archuletta <ue...@gm...> wrote:

>
>
>  On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
> >
> >
> >
> >  On 4/6/06, uel archuletta < ue...@gm...> wrote:
> >
> > > Sounds good. I have some additions to a few of your propositions. her=
e
> > > thay are
> > >
> > > 1. we have some package list we may be able to use to help in this
> > > they are in ftp in the VL6base folder.
> > > 2. I nominate you to build the base and get it setup for us. :)
> > >
> >
> >  OK
> >
> >
> >  3. sounds good, but do we have enough people to seperate into 2 groups=
?
> > >
> >
> >  If not 2 groups, then each dev can have 2 partitions for dev - std and
> > soho. This shouldn't be too bad a task if we have all the pkgs decided =
upon
> > at the beginning and hand out the workload equally. Remember, in the pa=
st
> > Robert did std by himself and I did soho by myself on top of std so it =
is
> > possible.
> >
>
> That is workable 2 seperate workloads if one has time/space they could
> work on both.
>
>
>
>   4. agree
> > > 5. agree
> > > 6. I along with others would like to see this borken down further.
> > > base-cli, dev, X, std, soho, some examples would be the package lists=
 in
> > > VL6base on ftp.
> > >
> >
> >
> >  base-cli and dev will have to be 1 since we can't work on a base
> > without dev tools.
> >
>
> this is where I get things mixed up so correct me if I am wrong. if we ar=
e
> building packages and populating a repo then we can build a base for the
> devs to build packages on that has all tools and X, and then build a base
> for the installer that has them seperated out. as long as we test the
> packages on this base as well.
>


I think this would create more work.  Apps built for SOHO would have
kde-centric additions wherever possible to integrate them better into the
desktop environment. While we may use the same apps for std, they should no=
t
have kde deps in them.  This is kind of like the issue you get if you try t=
o
install packages from linuxpackages.net - arts has a dep of gnome - wtf?
Whay would you build arts with a gnome dep. Same goes for apps for std that
might have a kde dep - not a good thing at all.

The base would be common to all, including X and dev.  std(WM's and
apps) and soho(KDE and apps) would then be built on top of the base.  Soho
would have KDE as its first build so that any other app installs after that
would be able to use kde hooks where needed.



>
>
>   X - if by this you mean xorg alone then I agree but if this includes
> > WM's,etc then no.
> >
>
> Vec asked if we couldnt include xfce in our xorg package since it is in
> both, and if we go down to the package level it woould simply mean adding=
 it
> to the metapackage
>
>


I really don't think xfce should be in SOHO.  IMHO, 99% of those that get
SOHO are getting it for kde and not xfce.  If they want xfce, they should
stick with std.  This would also allow us to make soho easier and better du=
e
to the fact that you wouldn't have to worry about menus and such as long as
a kde .desktop file was included with the packages.
Folks that are looking for xfce aren't looking for the bloat of kde and
those looking for the richness and integration of kde aren't looking for
xfce.  Again, we need to go back and look at the target market for these an=
d
not what we want out of it.  We could always add wm's and such to the repo
but I doubt they'd get a lot of hits.

Concentrating only on kde for soho would be the best bet.  choosing apps fo=
r
soho should also be centred around kde as well so they integrate properly
into the DE.  The maturity of the apps for kde is there now and we should
take advantage of that.

The only folks I know that run SOHO with xfce are vec and monty - lol. No
offense guys.

We need to focus on packages as that is what is really important. That is
why stuff like ubuntu, gentoo,etc have gained the popularity they have.
Folks don't have to go searching a million different places to get what the=
y
need. It is all available from a central source for the most part.

Linuxpackages and slacky.it are ok but they still have some goofyness to
them with deps of stuff that isn't needed.



>    7. I think there should be a seperation in release dates. 1 reason is
> > > Distrowatch another is easier for us to debug.
> > > 8.agree
> > > 9.agree
> > > 10.agree
> > > 11. see #7
> > > 12. I really like this idea
> > > 13. agree
> > > 14. agree
> > >
> > > some really good ideas here Tony.
> > > Thanks,
> > >
> > > Uel
> > >
> > >
> > > On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> > > >
> > > >  Sorry if this has already been decided upon but I haven't been mad=
e
> > > > aware of it so here goes.
> > > >
> > > > I have been looking at these as I'm sure some or all of you have as
> > > > well.
> > > >
> > > > I think we can work with these to build our base from source and
> > > > then expand on them in the future.
> > > >
> > > > There were a few of us on irc last night chatting about it.
> > > >
> > > > This is how I think we should move forward with this:
> > > >
> > > > 1 - as a group, decide on all the packages for both std vl and soho
> > > > before we start
> > > > 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k
> > > > source trees) - probably either myself or Uel or anyone that wants =
to take
> > > > ownership of this task - all base build scripts need to be correcte=
d for
> > > > arch,flags,etc
> > > > 3 - once the base is built, each developer is given a source tree o=
r
> > > > trees and they work on those on top of the base(vlbase.tgz).eg.
> > > > kde,xap,etc - all packages must be built on a virgin base except fo=
r soho -
> > > > 2 groups are needed here - std and soho and there will be some dupl=
ication
> > > > as std and soho should be treated as separate distros - all build s=
cripts
> > > > need to corrected for arch,flags,etc
> > > > 4 - we need to come up with SlackBuilds for the packages we include
> > > > that aren't in slack and split this up depending on how many pkgs t=
here are
> > > > 5 - upload all the built packages to the respective trees and each
> > > > of us install them for testing.
> > > > 6 - once testing is completed, we package these up for the cd into
> > > > vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related package=
s
> > > > should reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE
> > > > only and have all packages built for it using kde as a dep.
> > > > 7 - release beta std and soho at the same time
> > > > 8 - set a beta test schedule of 2 weeks
> > > > 9 - fix and release rc
> > > > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until
> > > > stable.
> > > > 11 - release final std and soho at the same time.
> > > > 12 - designate a dev for each versions - std and soho - whose
> > > > primary responsibility will be security patching
> > > > 13 - start working on extra packages for the repo
> > > > 14 - once there is a large repo of apps available, start the next
> > > > cycle at step 1
> > > >
> > > > Let me know what you all think.  Having this process more organized
> > > > and coordinated will allow us to work quicker and more efficiently =
giving us
> > > > more time to create the extra app repo that is needed to take VL to=
 the next
> > > > level. That way when Robert becomes rich from VL, he will share wit=
h all of
> > > > us - lol.
> > > >
> > > > Regards,
> > > >  Tony
> > > >
> > > >
> > >
> > >
> >
> >
>
>
>

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[uel a. <ue...@gm...>]

On 4/6/06, Tony Brijeski <tb...@gm...> wrote:
>
>
>
> On 4/6/06, uel archuletta <ue...@gm...> wrote:
>
> > Sounds good. I have some additions to a few of your propositions. here
> > thay are
> >
> > 1. we have some package list we may be able to use to help in this they
> > are in ftp in the VL6base folder.
> > 2. I nominate you to build the base and get it setup for us. :)
> >
>
> OK
>
>
>  3. sounds good, but do we have enough people to seperate into 2 groups?
> >
>
> If not 2 groups, then each dev can have 2 partitions for dev - std and
> soho. This shouldn't be too bad a task if we have all the pkgs decided up=
on
> at the beginning and hand out the workload equally. Remember, in the past
> Robert did std by himself and I did soho by myself on top of std so it is
> possible.
>

That is workable 2 seperate workloads if one has time/space they could work
on both.



4. agree
> > 5. agree
> > 6. I along with others would like to see this borken down further.
> > base-cli, dev, X, std, soho, some examples would be the package lists i=
n
> > VL6base on ftp.
> >
>
>
> base-cli and dev will have to be 1 since we can't work on a base without
> dev tools.
>

this is where I get things mixed up so correct me if I am wrong. if we are
building packages and populating a repo then we can build a base for the
devs to build packages on that has all tools and X, and then build a base
for the installer that has them seperated out. as long as we test the
packages on this base as well.




X - if by this you mean xorg alone then I agree but if this includes
> WM's,etc then no.
>

Vec asked if we couldnt include xfce in our xorg package since it is in
both, and if we go down to the package level it woould simply mean adding i=
t
to the metapackage


7. I think there should be a seperation in release dates. 1 reason is
> > Distrowatch another is easier for us to debug.
> > 8.agree
> > 9.agree
> > 10.agree
> > 11. see #7
> > 12. I really like this idea
> > 13. agree
> > 14. agree
> >
> > some really good ideas here Tony.
> > Thanks,
> >
> > Uel
> >
> >
> > On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> > >
> > >  Sorry if this has already been decided upon but I haven't been made
> > > aware of it so here goes.
> > >
> > > I have been looking at these as I'm sure some or all of you have as
> > > well.
> > >
> > > I think we can work with these to build our base from source and then
> > > expand on them in the future.
> > >
> > > There were a few of us on irc last night chatting about it.
> > >
> > > This is how I think we should move forward with this:
> > >
> > > 1 - as a group, decide on all the packages for both std vl and soho
> > > before we start
> > > 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k
> > > source trees) - probably either myself or Uel or anyone that wants to=
 take
> > > ownership of this task - all base build scripts need to be corrected =
for
> > > arch,flags,etc
> > > 3 - once the base is built, each developer is given a source tree or
> > > trees and they work on those on top of the base(vlbase.tgz).eg.
> > > kde,xap,etc - all packages must be built on a virgin base except for =
soho -
> > > 2 groups are needed here - std and soho and there will be some duplic=
ation
> > > as std and soho should be treated as separate distros - all build scr=
ipts
> > > need to corrected for arch,flags,etc
> > > 4 - we need to come up with SlackBuilds for the packages we include
> > > that aren't in slack and split this up depending on how many pkgs the=
re are
> > > 5 - upload all the built packages to the respective trees and each of
> > > us install them for testing.
> > > 6 - once testing is completed, we package these up for the cd into
> > > vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related packages
> > > should reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE
> > > only and have all packages built for it using kde as a dep.
> > > 7 - release beta std and soho at the same time
> > > 8 - set a beta test schedule of 2 weeks
> > > 9 - fix and release rc
> > > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until
> > > stable.
> > > 11 - release final std and soho at the same time.
> > > 12 - designate a dev for each versions - std and soho - whose primary
> > > responsibility will be security patching
> > > 13 - start working on extra packages for the repo
> > > 14 - once there is a large repo of apps available, start the next
> > > cycle at step 1
> > >
> > > Let me know what you all think.  Having this process more organized
> > > and coordinated will allow us to work quicker and more efficiently gi=
ving us
> > > more time to create the extra app repo that is needed to take VL to t=
he next
> > > level. That way when Robert becomes rich from VL, he will share with =
all of
> > > us - lol.
> > >
> > > Regards,
> > >  Tony
> > >
> > >
> >
> >
>

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[Tony B. <tb...@gm...>]

Agreed. We need a much better repo organization that follows the version
number. Having vl 5.1 and soho 5.1.1 using the 5.0 repo is confusing and
just bad altogether - lol.



On 4/6/06, Jose J. Rodriguez <jo...@gm...> wrote:
>
> I agree with most of what Tony proposes, but with uel's "fixes", lol.
>
> I might be jumping ahead here, but I do think we should start planning
> so the repo for VL6 has a better organization from the start, as
> discussed previously, something like official, unofficial, extras,
> unstable, etc, or any other naming convention. The thing is to
> separate the maintenance packages (allowing for a possible
> distro-update) from the extra apps and those which are development
> releases of apps.
>
> I must also restate my hope that beyond the base-cli bulk, the rest
> can be handled as packages with metapackages to define the "bulks".
> This would allow an "easy" install by selecting metapackages or an
> "advanced" install where most apps are listed for selection (probably
> not necessary to list libs) and the deps are handled automatically for
> those selected. For this, slapt-get might be a good choice to consider
> if it can be called from the installer in the initrd.
>
> Regards,
> Joe1962
>
>
> On 4/6/06, uel archuletta <ue...@gm...> wrote:
> > Sounds good. I have some additions to a few of your propositions. here
> thay
> > are
> >
> > 1. we have some package list we may be able to use to help in this they
> are
> > in ftp in the VL6base folder.
> > 2. I nominate you to build the base and get it setup for us. :)
> > 3. sounds good, but do we have enough people to seperate into 2 groups?
> > 4. agree
> > 5. agree
> > 6. I along with others would like to see this borken down further.
> base-cli,
> > dev, X, std, soho, some examples would be the package lists in VL6base
> on
> > ftp.
> > 7. I think there should be a seperation in release dates. 1 reason is
> > Distrowatch another is easier for us to debug.
> > 8.agree
> > 9.agree
> > 10.agree
> > 11. see #7
> > 12. I really like this idea
> > 13. agree
> > 14. agree
> >
> > some really good ideas here Tony.
> > Thanks,
> > Uel
> >
> >
> > On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> > >
> > >
> > > Sorry if this has already been decided upon but I haven't been made
> aware
> > of it so here goes.
> > >
> > > I have been looking at these as I'm sure some or all of you have as
> well.
> > >
> > > I think we can work with these to build our base from source and then
> > expand on them in the future.
> > >
> > > There were a few of us on irc last night chatting about it.
> > >
> > > This is how I think we should move forward with this:
> > >
> > > 1 - as a group, decide on all the packages for both std vl and soho
> before
> > we start
> > > 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k
> source
> > trees) - probably either myself or Uel or anyone that wants to take
> > ownership of this task - all base build scripts need to be corrected fo=
r
> > arch,flags,etc
> > > 3 - once the base is built, each developer is given a source tree or
> trees
> > and they work on those on top of the base(vlbase.tgz).eg. kde,xap,etc -
> all
> > packages must be built on a virgin base except for soho - 2 groups are
> > needed here - std and soho and there will be some duplication as std an=
d
> > soho should be treated as separate distros - all build scripts need to
> > corrected for arch,flags,etc
> > > 4 - we need to come up with SlackBuilds for the packages we include
> that
> > aren't in slack and split this up depending on how many pkgs there are
> > > 5 - upload all the built packages to the respective trees and each of
> us
> > install them for testing.
> > > 6 - once testing is completed, we package these up for the cd into
> > vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related packages
> should
> > reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE only and
> have
> > all packages built for it using kde as a dep.
> > > 7 - release beta std and soho at the same time
> > > 8 - set a beta test schedule of 2 weeks
> > > 9 - fix and release rc
> > > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until
> stable.
> > > 11 - release final std and soho at the same time.
> > > 12 - designate a dev for each versions - std and soho - whose primary
> > responsibility will be security patching
> > > 13 - start working on extra packages for the repo
> > > 14 - once there is a large repo of apps available, start the next
> cycle at
> > step 1
> > >
> > > Let me know what you all think.  Having this process more organized
> and
> > coordinated will allow us to work quicker and more efficiently giving u=
s
> > more time to create the extra app repo that is needed to take VL to the
> next
> > level. That way when Robert becomes rich from VL, he will share with al=
l
> of
> > us - lol.
> > >
> > > Regards,
> > >
> > > Tony
> > >
> >
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Vectorlinux-devel mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
>

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[Tony B. <tb...@gm...>]

On 4/6/06, uel archuletta <ue...@gm...> wrote:
>
> Sounds good. I have some additions to a few of your propositions. here
> thay are
>
> 1. we have some package list we may be able to use to help in this they
> are in ftp in the VL6base folder.
> 2. I nominate you to build the base and get it setup for us. :)
>

OK


 3. sounds good, but do we have enough people to seperate into 2 groups?
>

If not 2 groups, then each dev can have 2 partitions for dev - std and soho=
.
This shouldn't be too bad a task if we have all the pkgs decided upon at th=
e
beginning and hand out the workload equally. Remember, in the past Robert
did std by himself and I did soho by myself on top of std so it is possible=
.


 4. agree
> 5. agree
> 6. I along with others would like to see this borken down further.
> base-cli, dev, X, std, soho, some examples would be the package lists in
> VL6base on ftp.
>


base-cli and dev will have to be 1 since we can't work on a base without de=
v
tools.

X - if by this you mean xorg alone then I agree but if this includes
WM's,etc then no.


 7. I think there should be a seperation in release dates. 1 reason is
> Distrowatch another is easier for us to debug.
> 8.agree
> 9.agree
> 10.agree
> 11. see #7
> 12. I really like this idea
> 13. agree
> 14. agree
>
> some really good ideas here Tony.
> Thanks,
>
> Uel
>
>
> On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> >
> >  Sorry if this has already been decided upon but I haven't been made
> > aware of it so here goes.
> >
> > I have been looking at these as I'm sure some or all of you have as
> > well.
> >
> > I think we can work with these to build our base from source and then
> > expand on them in the future.
> >
> > There were a few of us on irc last night chatting about it.
> >
> > This is how I think we should move forward with this:
> >
> > 1 - as a group, decide on all the packages for both std vl and soho
> > before we start
> > 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k sourc=
e
> > trees) - probably either myself or Uel or anyone that wants to take
> > ownership of this task - all base build scripts need to be corrected fo=
r
> > arch,flags,etc
> > 3 - once the base is built, each developer is given a source tree or
> > trees and they work on those on top of the base(vlbase.tgz).eg.
> > kde,xap,etc - all packages must be built on a virgin base except for so=
ho -
> > 2 groups are needed here - std and soho and there will be some duplicat=
ion
> > as std and soho should be treated as separate distros - all build scrip=
ts
> > need to corrected for arch,flags,etc
> > 4 - we need to come up with SlackBuilds for the packages we include tha=
t
> > aren't in slack and split this up depending on how many pkgs there are
> > 5 - upload all the built packages to the respective trees and each of u=
s
> > install them for testing.
> > 6 - once testing is completed, we package these up for the cd into
> > vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related packages
> > should reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE onl=
y
> > and have all packages built for it using kde as a dep.
> > 7 - release beta std and soho at the same time
> > 8 - set a beta test schedule of 2 weeks
> > 9 - fix and release rc
> > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until
> > stable.
> > 11 - release final std and soho at the same time.
> > 12 - designate a dev for each versions - std and soho - whose primary
> > responsibility will be security patching
> > 13 - start working on extra packages for the repo
> > 14 - once there is a large repo of apps available, start the next cycle
> > at step 1
> >
> > Let me know what you all think.  Having this process more organized and
> > coordinated will allow us to work quicker and more efficiently giving u=
s
> > more time to create the extra app repo that is needed to take VL to the=
 next
> > level. That way when Robert becomes rich from VL, he will share with al=
l of
> > us - lol.
> >
> > Regards,
> >  Tony
> >
> >
>
>

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[Jose J. R. <jo...@gm...>]

I agree with most of what Tony proposes, but with uel's "fixes", lol.

I might be jumping ahead here, but I do think we should start planning
so the repo for VL6 has a better organization from the start, as
discussed previously, something like official, unofficial, extras,
unstable, etc, or any other naming convention. The thing is to
separate the maintenance packages (allowing for a possible
distro-update) from the extra apps and those which are development
releases of apps.

I must also restate my hope that beyond the base-cli bulk, the rest
can be handled as packages with metapackages to define the "bulks".
This would allow an "easy" install by selecting metapackages or an
"advanced" install where most apps are listed for selection (probably
not necessary to list libs) and the deps are handled automatically for
those selected. For this, slapt-get might be a good choice to consider
if it can be called from the installer in the initrd.

Regards,
Joe1962


On 4/6/06, uel archuletta <ue...@gm...> wrote:
> Sounds good. I have some additions to a few of your propositions. here th=
ay
> are
>
> 1. we have some package list we may be able to use to help in this they a=
re
> in ftp in the VL6base folder.
> 2. I nominate you to build the base and get it setup for us. :)
> 3. sounds good, but do we have enough people to seperate into 2 groups?
> 4. agree
> 5. agree
> 6. I along with others would like to see this borken down further. base-c=
li,
> dev, X, std, soho, some examples would be the package lists in VL6base on
> ftp.
> 7. I think there should be a seperation in release dates. 1 reason is
> Distrowatch another is easier for us to debug.
> 8.agree
> 9.agree
> 10.agree
> 11. see #7
> 12. I really like this idea
> 13. agree
> 14. agree
>
> some really good ideas here Tony.
> Thanks,
> Uel
>
>
> On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
> >
> >
> > Sorry if this has already been decided upon but I haven't been made awa=
re
> of it so here goes.
> >
> > I have been looking at these as I'm sure some or all of you have as wel=
l.
> >
> > I think we can work with these to build our base from source and then
> expand on them in the future.
> >
> > There were a few of us on irc last night chatting about it.
> >
> > This is how I think we should move forward with this:
> >
> > 1 - as a group, decide on all the packages for both std vl and soho bef=
ore
> we start
> > 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k sourc=
e
> trees) - probably either myself or Uel or anyone that wants to take
> ownership of this task - all base build scripts need to be corrected for
> arch,flags,etc
> > 3 - once the base is built, each developer is given a source tree or tr=
ees
> and they work on those on top of the base(vlbase.tgz).eg. kde,xap,etc - a=
ll
> packages must be built on a virgin base except for soho - 2 groups are
> needed here - std and soho and there will be some duplication as std and
> soho should be treated as separate distros - all build scripts need to
> corrected for arch,flags,etc
> > 4 - we need to come up with SlackBuilds for the packages we include tha=
t
> aren't in slack and split this up depending on how many pkgs there are
> > 5 - upload all the built packages to the respective trees and each of u=
s
> install them for testing.
> > 6 - once testing is completed, we package these up for the cd into
> vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related packages shou=
ld
> reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE only and hav=
e
> all packages built for it using kde as a dep.
> > 7 - release beta std and soho at the same time
> > 8 - set a beta test schedule of 2 weeks
> > 9 - fix and release rc
> > 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until stabl=
e.
> > 11 - release final std and soho at the same time.
> > 12 - designate a dev for each versions - std and soho - whose primary
> responsibility will be security patching
> > 13 - start working on extra packages for the repo
> > 14 - once there is a large repo of apps available, start the next cycle=
 at
> step 1
> >
> > Let me know what you all think.  Having this process more organized and
> coordinated will allow us to work quicker and more efficiently giving us
> more time to create the extra app repo that is needed to take VL to the n=
ext
> level. That way when Robert becomes rich from VL, he will share with all =
of
> us - lol.
> >
> > Regards,
> >
> > Tony
> >
>
>

Re: [Vectorlinux-devel] Slack Builds and VL - my suggestions

[uel a. <ue...@gm...>]

Sounds good. I have some additions to a few of your propositions. here thay
are

1. we have some package list we may be able to use to help in this they are
in ftp in the VL6base folder.
2. I nominate you to build the base and get it setup for us. :)
3. sounds good, but do we have enough people to seperate into 2 groups?
4. agree
5. agree
6. I along with others would like to see this borken down further. base-cli=
,
dev, X, std, soho, some examples would be the package lists in VL6base on
ftp.
7. I think there should be a seperation in release dates. 1 reason is
Distrowatch another is easier for us to debug.
8.agree
9.agree
10.agree
11. see #7
12. I really like this idea
13. agree
14. agree

some really good ideas here Tony.
Thanks,
Uel

On 4/5/06, Tony Brijeski <tb...@gm...> wrote:
>
> Sorry if this has already been decided upon but I haven't been made aware
> of it so here goes.
>
> I have been looking at these as I'm sure some or all of you have as well.
>
> I think we can work with these to build our base from source and then
> expand on them in the future.
>
> There were a few of us on irc last night chatting about it.
>
> This is how I think we should move forward with this:
>
> 1 - as a group, decide on all the packages for both std vl and soho befor=
e
> we start
> 2 - 1 person designated to build the bare minimum base(a/ap/d/l/k source
> trees) - probably either myself or Uel or anyone that wants to take
> ownership of this task - all base build scripts need to be corrected for
> arch,flags,etc
> 3 - once the base is built, each developer is given a source tree or tree=
s
> and they work on those on top of the base(vlbase.tgz).eg. kde,xap,etc -
> all packages must be built on a virgin base except for soho - 2 groups ar=
e
> needed here - std and soho and there will be some duplication as std and
> soho should be treated as separate distros - all build scripts need to
> corrected for arch,flags,etc
> 4 - we need to come up with SlackBuilds for the packages we include that
> aren't in slack and split this up depending on how many pkgs there are
> 5 - upload all the built packages to the respective trees and each of us
> install them for testing.
> 6 - once testing is completed, we package these up for the cd into
> vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related packages
> should reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE only
> and have all packages built for it using kde as a dep.
> 7 - release beta std and soho at the same time
> 8 - set a beta test schedule of 2 weeks
> 9 - fix and release rc
> 10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until stable.
> 11 - release final std and soho at the same time.
> 12 - designate a dev for each versions - std and soho - whose primary
> responsibility will be security patching
> 13 - start working on extra packages for the repo
> 14 - once there is a large repo of apps available, start the next cycle a=
t
> step 1
>
> Let me know what you all think.  Having this process more organized and
> coordinated will allow us to work quicker and more efficiently giving us
> more time to create the extra app repo that is needed to take VL to the n=
ext
> level. That way when Robert becomes rich from VL, he will share with all =
of
> us - lol.
>
> Regards,
> Tony
>
>

[Vectorlinux-devel] Slack Builds and VL - my suggestions

[Tony B. <tb...@gm...>]

Sorry if this has already been decided upon but I haven't been made aware o=
f
it so here goes.

I have been looking at these as I'm sure some or all of you have as well.

I think we can work with these to build our base from source and then expan=
d
on them in the future.

There were a few of us on irc last night chatting about it.

This is how I think we should move forward with this:

1 - as a group, decide on all the packages for both std vl and soho before
we start
2 - 1 person designated to build the bare minimum base(a/ap/d/l/k source
trees) - probably either myself or Uel or anyone that wants to take
ownership of this task - all base build scripts need to be corrected for
arch,flags,etc
3 - once the base is built, each developer is given a source tree or trees
and they work on those on top of the base(vlbase.tgz).eg. kde,xap,etc - all
packages must be built on a virgin base except for soho - 2 groups are
needed here - std and soho and there will be some duplication as std and
soho should be treated as separate distros - all build scripts need to
corrected for arch,flags,etc
4 - we need to come up with SlackBuilds for the packages we include that
aren't in slack and split this up depending on how many pkgs there are
5 - upload all the built packages to the respective trees and each of us
install them for testing.
6 - once testing is completed, we package these up for the cd into
vl-base.tgz,vl-std.tgz, and vl-soho.tgz - all X and related packages should
reside in vl-std.tgz and vl-soho.tgz so that SOHO can be KDE only and have
all packages built for it using kde as a dep.
7 - release beta std and soho at the same time
8 - set a beta test schedule of 2 weeks
9 - fix and release rc
10 - set an rc test schedule of 2 weeks and repeat 9 and 10 until stable.
11 - release final std and soho at the same time.
12 - designate a dev for each versions - std and soho - whose primary
responsibility will be security patching
13 - start working on extra packages for the repo
14 - once there is a large repo of apps available, start the next cycle at
step 1

Let me know what you all think.  Having this process more organized and
coordinated will allow us to work quicker and more efficiently giving us
more time to create the extra app repo that is needed to take VL to the nex=
t
level. That way when Robert becomes rich from VL, he will share with all of
us - lol.

Regards,
Tony

Re: [Vectorlinux-devel] 64-bit Linux and Kernel 2.6.16

[Tony B. <tb...@gm...>]

I think I will but it isn't slackware 64 which would be my choice.

soho 5.1.1 works great - fast, has all the apps I need and what I didn't
have I got from slacky.it.

The speed increase with native 64-bit is great though. firefox is lightning
fast.



On 3/23/06, uel archuletta <ue...@gm...> wrote:
>
> I havent  been able to get 2.6.16 downloaded yet I am stuck with subpar
> internet for few days while they rewire my house.
> most of the day  have no internet at all.
> I tried slamd64 a little while baack and it seemed pretty stable.
> have you thought about trying that one?
>
>
> On 3/23/06, Tony Brijeski <tb...@gm...> wrote:
> >
> > After another day with Kanotix 64 and some more testing, I found quite =
a
> > few things to be unstable and crashing.  Multimedia is crap - the media
> > players crash.  IVTV drivers do not work - compile but do not work.  Lo=
ts of
> > KDE bugs that cause many things to segfault.
> >
> > The speed was great but the instability sucks.  Might give gentoo 64 a
> > shot next - lol.
> >
> > Has anyone tried the 2.6.16 kernel yet?
> >
> >
> >
> > On 3/22/06, Tony Brijeski <tb...@gm...> wrote:
> > >
> > >
> > >
> > > On 3/22/06, Sriram Durbha < sri...@gm...> wrote:
> > > >
> > > >
> > > >
> > > > On 3/22/06, Tony Brijeski < tb...@gm...> wrote:
> > > > >
> > > > >
> > > > > Kanotix and Kanotix 64 are live cd's that you can install - they
> > > > > were originally based on Knoppix.  I still think the LiveCD with =
install
> > > > > option is the way to go in the future.
> > > > >
> > > > >
> > > > >
> > > > I am so glad you also think like this. unfortunately when i had put
> > > > this idea forth it was in a different thread and did not get enough
> > > > momentum. however, thanks to uel's work, now every one is realizing=
 the
> > > > benefits of liveCD with install option.  also some how our liveCD e=
xperience
> > > > is really not comparable to many others, though our core OS is mile=
as ahead
> > > > of other offerings.
> > > > But since this is our first liveCD , we can come across several
> > > > areas of improvement.
> > > >
> > >
> > >
> > > I've always been a fan of Live CD's.  Thats why I created the first
> > > few live cd's for VL.  They were as much a selfish venture as they we=
re to
> > > allow people to have a portable VL.  Uel took it one step further by =
working
> > > on the install portion and that is exactly what was needed.  I would =
imagine
> > > with the next generation of the kernel - 2.8.x, most of the current V=
L
> > > userbase will not be able to run it anyway.  Lots are having issues w=
ith the
> > > 2.6 kernel as it is.  2.8.x will no doubt be optimized and built
> > > around the 64-bit platform even though the kernel is a multiarch thin=
g.
> > >
> > > as for my thoughts on 64bit.  for a long time to come,  most people
> > > > will still buy 32 bit systems for home/soho use.  but most new syst=
ems might
> > > > be multi-core. say after 3 years from now, i would suspect most new=
 machines
> > > > will still be 32 bit but multi core.  For most desktop applications=
[
> > > > photoshop, media encodeers not included ] 32 bit cpus are more than=
 enough.
> > > > and the address space too. infact apple did some research and found=
 that
> > > > graphics performance actually slowed down if they made a complete s=
witch to
> > > > 64 bit arch.!!
> > > >
> > >
> > > Everywhere up here in Canada is selling 64-bit systems as standard
> > > right now.
> > >
> > > Intel is the only ones that are staying with 32-bit for now and since
> > > apple is using them, it makes marketing sense for them to say 64-bit =
isn't
> > > as good.  As far as gaming performance, it has everything to do with =
the
> > > drivers and nvidia is still having some issues with their drivers but=
 they
> > > are improving.  They do have the EM64T which are basically just P4's =
that
> > > are cloning AMD64 instruction set.
> > >
> > > 64-bit AMD's have been here for 3 years already and with Vista just
> > > around the corner, 64-bit will be the standard by years end.
> > >
> > > No doubt 32-bit will be around for a while but it will not be the
> > > standard.
> > >
> > >
> > > so we can happily tag along with slack for some time to come.  but
> > > > ofcourse if we do want to make a 64 bit os it would be cool :) ;
> > > > cheers
> > > > ram
> > > >
> > >
> > > I have a feeling Slackware will die unless it goes to 64-bit.  Most o=
f
> > > the userbase that has the savvy to run a stock slackware setup will m=
ost
> > > likely also be the folks that build their own systems and will be goi=
ng to
> > > 64-bit soon if not already like myself.  All the reading I have done =
on
> > > 64-bit distros mainly pointed to SuSE as the best choice.  While it m=
ay be
> > > easier than running debian, it was nowhere near as responsive.  Havin=
g a
> > > 64-bit CPU and seeing what it can do has spoiled me.  I still run SOH=
O on 2
> > > boxes at home(wife's laptop - p3-500 and kids desktop - p3 1G) and it=
 runs
> > > great.  I also have it still on my new box as it is completely setup =
for
> > > everything I need it to do and won't be getting rid of it anytime soo=
n.
> > >
> > > The same thing happened when P4 and AthlonXP came out - folks were
> > > happy with their P3's and Athlon's but once they saw the difference a=
nd PC
> > > vendors starting only shipping the new CPU's, they were forced to go =
with
> > > them.
> > >
> > >
> > > To give you an idea of how debian 64-bit linux runs on my humble
> > > 64-bit system, I would liken it to how regular VL with icewm ran on m=
y
> > > AthlonXP 2400+ - very quick and almost instant response.  A big diffe=
rence
> > > from SuSE 64-bit.
> > >
> > > My main hard drive on my 64-bit system is now about to die and I will
> > > be replacing it with a sata drive which is at least 200GB in size so =
I will
> > > have lots of "devel" and "play" space.  It will also free up my slave=
 drive
> > > which has SOHO on it for other uses.
> > >
> > >
> >
>

Re: [Vectorlinux-devel] 64-bit Linux and Kernel 2.6.16

[uel a. <ue...@gm...>]

I havent  been able to get 2.6.16 downloaded yet I am stuck with subpar
internet for few days while they rewire my house.
most of the day  have no internet at all.
I tried slamd64 a little while baack and it seemed pretty stable.
have you thought about trying that one?

On 3/23/06, Tony Brijeski <tb...@gm...> wrote:
>
> After another day with Kanotix 64 and some more testing, I found quite a
> few things to be unstable and crashing.  Multimedia is crap - the media
> players crash.  IVTV drivers do not work - compile but do not work.  Lots=
 of
> KDE bugs that cause many things to segfault.
>
> The speed was great but the instability sucks.  Might give gentoo 64 a
> shot next - lol.
>
> Has anyone tried the 2.6.16 kernel yet?
>
>
>
> On 3/22/06, Tony Brijeski <tb...@gm...> wrote:
> >
> >
> >
> > On 3/22/06, Sriram Durbha < sri...@gm...> wrote:
> > >
> > >
> > >
> > > On 3/22/06, Tony Brijeski < tb...@gm...> wrote:
> > > >
> > > >
> > > > Kanotix and Kanotix 64 are live cd's that you can install - they
> > > > were originally based on Knoppix.  I still think the LiveCD with in=
stall
> > > > option is the way to go in the future.
> > > >
> > > >
> > > >
> > > I am so glad you also think like this. unfortunately when i had put
> > > this idea forth it was in a different thread and did not get enough
> > > momentum. however, thanks to uel's work, now every one is realizing t=
he
> > > benefits of liveCD with install option.  also some how our liveCD exp=
erience
> > > is really not comparable to many others, though our core OS is mileas=
 ahead
> > > of other offerings.
> > > But since this is our first liveCD , we can come across several areas
> > > of improvement.
> > >
> >
> >
> > I've always been a fan of Live CD's.  Thats why I created the first few
> > live cd's for VL.  They were as much a selfish venture as they were to =
allow
> > people to have a portable VL.  Uel took it one step further by working =
on
> > the install portion and that is exactly what was needed.  I would imagi=
ne
> > with the next generation of the kernel - 2.8.x, most of the current VL
> > userbase will not be able to run it anyway.  Lots are having issues wit=
h the
> > 2.6 kernel as it is.  2.8.x will no doubt be optimized and built around
> > the 64-bit platform even though the kernel is a multiarch thing.
> >
> > as for my thoughts on 64bit.  for a long time to come,  most people wil=
l
> > > still buy 32 bit systems for home/soho use.  but most new systems mig=
ht be
> > > multi-core. say after 3 years from now, i would suspect most new mach=
ines
> > > will still be 32 bit but multi core.  For most desktop applications[
> > > photoshop, media encodeers not included ] 32 bit cpus are more than e=
nough.
> > > and the address space too. infact apple did some research and found t=
hat
> > > graphics performance actually slowed down if they made a complete swi=
tch to
> > > 64 bit arch.!!
> > >
> >
> > Everywhere up here in Canada is selling 64-bit systems as standard righ=
t
> > now.
> >
> > Intel is the only ones that are staying with 32-bit for now and since
> > apple is using them, it makes marketing sense for them to say 64-bit is=
n't
> > as good.  As far as gaming performance, it has everything to do with th=
e
> > drivers and nvidia is still having some issues with their drivers but t=
hey
> > are improving.  They do have the EM64T which are basically just P4's th=
at
> > are cloning AMD64 instruction set.
> >
> > 64-bit AMD's have been here for 3 years already and with Vista just
> > around the corner, 64-bit will be the standard by years end.
> >
> > No doubt 32-bit will be around for a while but it will not be the
> > standard.
> >
> >
> > so we can happily tag along with slack for some time to come.  but
> > > ofcourse if we do want to make a 64 bit os it would be cool :) ;
> > > cheers
> > > ram
> > >
> >
> > I have a feeling Slackware will die unless it goes to 64-bit.  Most of
> > the userbase that has the savvy to run a stock slackware setup will mos=
t
> > likely also be the folks that build their own systems and will be going=
 to
> > 64-bit soon if not already like myself.  All the reading I have done on
> > 64-bit distros mainly pointed to SuSE as the best choice.  While it may=
 be
> > easier than running debian, it was nowhere near as responsive.  Having =
a
> > 64-bit CPU and seeing what it can do has spoiled me.  I still run SOHO =
on 2
> > boxes at home(wife's laptop - p3-500 and kids desktop - p3 1G) and it r=
uns
> > great.  I also have it still on my new box as it is completely setup fo=
r
> > everything I need it to do and won't be getting rid of it anytime soon.
> >
> > The same thing happened when P4 and AthlonXP came out - folks were happ=
y
> > with their P3's and Athlon's but once they saw the difference and PC ve=
ndors
> > starting only shipping the new CPU's, they were forced to go with them.
> >
> >
> > To give you an idea of how debian 64-bit linux runs on my humble 64-bit
> > system, I would liken it to how regular VL with icewm ran on my AthlonX=
P
> > 2400+ - very quick and almost instant response.  A big difference from =
SuSE
> > 64-bit.
> >
> > My main hard drive on my 64-bit system is now about to die and I will b=
e
> > replacing it with a sata drive which is at least 200GB in size so I wil=
l
> > have lots of "devel" and "play" space.  It will also free up my slave d=
rive
> > which has SOHO on it for other uses.
> >
> >
>

Re: [Vectorlinux-devel] 64-bit Linux and Kernel 2.6.16

[Tony B. <tb...@gm...>]

After another day with Kanotix 64 and some more testing, I found quite a fe=
w
things to be unstable and crashing.  Multimedia is crap - the media players
crash.  IVTV drivers do not work - compile but do not work.  Lots of KDE
bugs that cause many things to segfault.

The speed was great but the instability sucks.  Might give gentoo 64 a shot
next - lol.

Has anyone tried the 2.6.16 kernel yet?


On 3/22/06, Tony Brijeski <tb...@gm...> wrote:
>
>
>
> On 3/22/06, Sriram Durbha <sri...@gm...> wrote:
> >
> >
> >
> > On 3/22/06, Tony Brijeski < tb...@gm...> wrote:
> > >
> > >
> > > Kanotix and Kanotix 64 are live cd's that you can install - they were
> > > originally based on Knoppix.  I still think the LiveCD with install o=
ption
> > > is the way to go in the future.
> > >
> > >
> > >
> > I am so glad you also think like this. unfortunately when i had put thi=
s
> > idea forth it was in a different thread and did not get enough momentum=
.
> > however, thanks to uel's work, now every one is realizing the benefits =
of
> > liveCD with install option.  also some how our liveCD experience is rea=
lly
> > not comparable to many others, though our core OS is mileas ahead of ot=
her
> > offerings.
> > But since this is our first liveCD , we can come across several areas o=
f
> > improvement.
> >
>
>
> I've always been a fan of Live CD's.  Thats why I created the first few
> live cd's for VL.  They were as much a selfish venture as they were to al=
low
> people to have a portable VL.  Uel took it one step further by working on
> the install portion and that is exactly what was needed.  I would imagine
> with the next generation of the kernel - 2.8.x, most of the current VL
> userbase will not be able to run it anyway.  Lots are having issues with =
the
> 2.6 kernel as it is.  2.8.x will no doubt be optimized and built around
> the 64-bit platform even though the kernel is a multiarch thing.
>
> as for my thoughts on 64bit.  for a long time to come,  most people will
> > still buy 32 bit systems for home/soho use.  but most new systems might=
 be
> > multi-core. say after 3 years from now, i would suspect most new machin=
es
> > will still be 32 bit but multi core.  For most desktop applications[
> > photoshop, media encodeers not included ] 32 bit cpus are more than eno=
ugh.
> > and the address space too. infact apple did some research and found tha=
t
> > graphics performance actually slowed down if they made a complete switc=
h to
> > 64 bit arch.!!
> >
>
> Everywhere up here in Canada is selling 64-bit systems as standard right
> now.
>
> Intel is the only ones that are staying with 32-bit for now and since
> apple is using them, it makes marketing sense for them to say 64-bit isn'=
t
> as good.  As far as gaming performance, it has everything to do with the
> drivers and nvidia is still having some issues with their drivers but the=
y
> are improving.  They do have the EM64T which are basically just P4's that
> are cloning AMD64 instruction set.
>
> 64-bit AMD's have been here for 3 years already and with Vista just aroun=
d
> the corner, 64-bit will be the standard by years end.
>
> No doubt 32-bit will be around for a while but it will not be the
> standard.
>
>
> so we can happily tag along with slack for some time to come.  but
> > ofcourse if we do want to make a 64 bit os it would be cool :) ;
> > cheers
> > ram
> >
>
> I have a feeling Slackware will die unless it goes to 64-bit.  Most of th=
e
> userbase that has the savvy to run a stock slackware setup will most like=
ly
> also be the folks that build their own systems and will be going to 64-bi=
t
> soon if not already like myself.  All the reading I have done on 64-bit
> distros mainly pointed to SuSE as the best choice.  While it may be easie=
r
> than running debian, it was nowhere near as responsive.  Having a 64-bit =
CPU
> and seeing what it can do has spoiled me.  I still run SOHO on 2 boxes at
> home(wife's laptop - p3-500 and kids desktop - p3 1G) and it runs great. =
 I
> also have it still on my new box as it is completely setup for everything=
 I
> need it to do and won't be getting rid of it anytime soon.
>
> The same thing happened when P4 and AthlonXP came out - folks were happy
> with their P3's and Athlon's but once they saw the difference and PC vend=
ors
> starting only shipping the new CPU's, they were forced to go with them.
>
>
> To give you an idea of how debian 64-bit linux runs on my humble 64-bit
> system, I would liken it to how regular VL with icewm ran on my AthlonXP
> 2400+ - very quick and almost instant response.  A big difference from Su=
SE
> 64-bit.
>
> My main hard drive on my 64-bit system is now about to die and I will be
> replacing it with a sata drive which is at least 200GB in size so I will
> have lots of "devel" and "play" space.  It will also free up my slave dri=
ve
> which has SOHO on it for other uses.
>
>

Re: [Vectorlinux-devel] 64-bit Linux and Kernel 2.6.16

[Tony B. <tb...@gm...>]

On 3/22/06, Sriram Durbha <sri...@gm...> wrote:
>
>
>
> On 3/22/06, Tony Brijeski <tb...@gm...> wrote:
> >
> >
> > Kanotix and Kanotix 64 are live cd's that you can install - they were
> > originally based on Knoppix.  I still think the LiveCD with install opt=
ion
> > is the way to go in the future.
> >
> >
> >
> I am so glad you also think like this. unfortunately when i had put this
> idea forth it was in a different thread and did not get enough momentum.
> however, thanks to uel's work, now every one is realizing the benefits of
> liveCD with install option.  also some how our liveCD experience is reall=
y
> not comparable to many others, though our core OS is mileas ahead of othe=
r
> offerings.
> But since this is our first liveCD , we can come across several areas of
> improvement.
>


I've always been a fan of Live CD's.  Thats why I created the first few liv=
e
cd's for VL.  They were as much a selfish venture as they were to allow
people to have a portable VL.  Uel took it one step further by working on
the install portion and that is exactly what was needed.  I would imagine
with the next generation of the kernel - 2.8.x, most of the current VL
userbase will not be able to run it anyway.  Lots are having issues with th=
e
2.6 kernel as it is.  2.8.x will no doubt be optimized and built around the
64-bit platform even though the kernel is a multiarch thing.

as for my thoughts on 64bit.  for a long time to come,  most people will
> still buy 32 bit systems for home/soho use.  but most new systems might b=
e
> multi-core. say after 3 years from now, i would suspect most new machines
> will still be 32 bit but multi core.  For most desktop applications[
> photoshop, media encodeers not included ] 32 bit cpus are more than enoug=
h.
> and the address space too. infact apple did some research and found that
> graphics performance actually slowed down if they made a complete switch =
to
> 64 bit arch.!!
>

Everywhere up here in Canada is selling 64-bit systems as standard right
now.

Intel is the only ones that are staying with 32-bit for now and since apple
is using them, it makes marketing sense for them to say 64-bit isn't as
good.  As far as gaming performance, it has everything to do with the
drivers and nvidia is still having some issues with their drivers but they
are improving.  They do have the EM64T which are basically just P4's that
are cloning AMD64 instruction set.

64-bit AMD's have been here for 3 years already and with Vista just around
the corner, 64-bit will be the standard by years end.

No doubt 32-bit will be around for a while but it will not be the standard.

so we can happily tag along with slack for some time to come.  but ofcourse
> if we do want to make a 64 bit os it would be cool :) ;
> cheers
> ram
>

I have a feeling Slackware will die unless it goes to 64-bit.  Most of the
userbase that has the savvy to run a stock slackware setup will most likely
also be the folks that build their own systems and will be going to 64-bit
soon if not already like myself.  All the reading I have done on 64-bit
distros mainly pointed to SuSE as the best choice.  While it may be easier
than running debian, it was nowhere near as responsive.  Having a 64-bit CP=
U
and seeing what it can do has spoiled me.  I still run SOHO on 2 boxes at
home(wife's laptop - p3-500 and kids desktop - p3 1G) and it runs great.  I
also have it still on my new box as it is completely setup for everything I
need it to do and won't be getting rid of it anytime soon.

The same thing happened when P4 and AthlonXP came out - folks were happy
with their P3's and Athlon's but once they saw the difference and PC vendor=
s
starting only shipping the new CPU's, they were forced to go with them.


To give you an idea of how debian 64-bit linux runs on my humble 64-bit
system, I would liken it to how regular VL with icewm ran on my AthlonXP
2400+ - very quick and almost instant response.  A big difference from SuSE
64-bit.

My main hard drive on my 64-bit system is now about to die and I will be
replacing it with a sata drive which is at least 200GB in size so I will
have lots of "devel" and "play" space.  It will also free up my slave drive
which has SOHO on it for other uses.

Re: [Vectorlinux-devel] 64-bit Linux and Kernel 2.6.16

[Sriram D. <sri...@gm...>]

On 3/22/06, Tony Brijeski <tb...@gm...> wrote:
>
>
> Kanotix and Kanotix 64 are live cd's that you can install - they were
> originally based on Knoppix.  I still think the LiveCD with install optio=
n
> is the way to go in the future.
>
>
>
I am so glad you also think like this. unfortunately when i had put this
idea forth it was in a different thread and did not get enough momentum.
however, thanks to uel's work, now every one is realizing the benefits of
liveCD with install option.  also some how our liveCD experience is really
not comparable to many others, though our core OS is mileas ahead of other
offerings.
But since this is our first liveCD , we can come across several areas of
improvement.

as for my thoughts on 64bit.  for a long time to come,  most people will
still buy 32 bit systems for home/soho use.  but most new systems might be
multi-core. say after 3 years from now, i would suspect most new machines
will still be 32 bit but multi core.  For most desktop applications[
photoshop, media encodeers not included ] 32 bit cpus are more than enough.
and the address space too. infact apple did some research and found that
graphics performance actually slowed down if they made a complete switch to
64 bit arch.!!

so we can happily tag along with slack for some time to come.  but ofcourse
if we do want to make a 64 bit os it would be cool :) ;
cheers
ram

Re: [Vectorlinux-devel] 64-bit Linux and Kernel 2.6.16

[Tony B. <tb...@gm...>]

I tried Kanotix 64 out last night which is basically the 64-bit version of
debian sid.

Much better than Suse 10.0.  I never really liked yast and how they do the
init scripts stuff.

Anyway, Kanotix is running pretty well and for the 64-bit apps, there is a
noticeable speed increase.  There wasn't as much on SuSE but debian is
flying.

I still think we should stick with 32-bit for now anyway.  64-bit will be
harder to maintain as we won't be able to start from a slack base - it woul=
d
be a whole new distro.

32-bit 3d gaming on the 64-bit OS is still a bit behind native 32 bit gamin=
g
in terms of FPS but I think that has to do with the nvidia drivers.

Kanotix and Kanotix 64 are live cd's that you can install - they were
originally based on Knoppix.  I still think the LiveCD with install option
is the way to go in the future.

I am going to stick with Kanotix(Debian) for the 64-bit stuff on that box
for now.  I also have SOHO 5.1.1 on it.  SOHO keeps up pretty well to SuSE
64-bit but not to Kanotix64.



On 3/22/06, Robert Lange <vec...@ya...> wrote:
>
>
> --- Tony Brijeski <tb...@gm...> wrote:
>
> > On 3/21/06, Vanger <fa...@gm...> wrote:
> > >
> > > > Kernel 2.6.16 is out.  Lets all try it out and
> > see if we can do the
> > > uevent
> > > > udev thing instead of hotplug and udev together.
>
>
> Here is a link I found for implementing the new udev
> on slack based systems. This requires at least the
> kernel 2.6.15 to work and 2.6.16 came out yesterday.
> This may require a bit of hacking to run nicely on
> vector but it's a start.........:)
> Cheers,
> Vec
> http://piterpunk.info02.com.br/extra/
>
>
> > > Just downloaded, will try.
> > >
> > > > Anyone who tries to say 64-bit is much better
> > than 32-bit probably
> > > doesn't
> > > > know what they are talking about and are just
> > going along with AMD and
> > > Intel
> > > > hype about 64-bit.
> > > Well, the kernel compiles on Slamd64 in about 1.5
> > times faster, then
> > > on VL. But that does not overweight the libraries'
> > troubles.
> >
> >
> > Kernel compiles will be faster due to the 64 bit
> > registers but overall speed
> > is not much different.  There is some difference
> > with 64 bit native apps but
> > not enough to justify losing the ease of use of 32
> > bit distros.  32-bit apps
> > run the same on 64 as they do on 32 unless they
> > heavily use peripherals via
> > the kernel which would speed them up a bit as well.
> >
> > > My Sempron 2800+( 1.6 Gig but
> > > > overclocked to 2.0 gig 200fsbX10) socket 754 cpu
> > on the k8n mobo
> > > How did you do it? 2800+ has locked multiplier 8x.
> >
> >
> >
> > My mistake - lol.  I meant to write 250x8 for 2.0
> > Gig.  Yes the x86_64 cpus
> > are multiplier locked.  My mobo allows me to raise
> > the cpu fsb independant
> > of agp and memory speed.
> >
> > > runs about the same as my old AthlonXP 2400+(2.0
> > Gig
> > > Well, usual system tasks are nearly the same. When
> > you are doing some
> > > math and optimise the program for your
> > architecture, K8 performs
> > > really better, then K7.
> >
> >
> > Yes but there are very few applications that take
> > full advantage of the
> > 64-bit architecture at this time.  Some have been
> > rewritten to include the
> > 64 bit registers but not as optimized as they should
> > be.  They are basically
> > ports of 32 bit.  This will hopefully change in the
> > future.
> >
> > I'm going to give Kanotix 64 a shot this evening
> > which is just debian 64 but
> > I will also have to setup a 32-bit chroot
> > environment for it or try the
> > ia32-libs install to see if that works for 32 bit
> > apps.
> >
> > I don't think simply installing a kernel that is
> > x86_64 optimized would do
> > anything without using a 64-bit compiler and
> > recompiling all libraries that
> > have 64-bit ports.
> >
> > If VL goes 64-bit, it would have to be total 64-bit
> > with 32 bit libs for
> > those apps that won't compile under 64 bit.
> >
> >
> >
> -------------------------------------------------------
> > > This SF.Net email is sponsored by xPML, a
> > groundbreaking scripting
> > > language
> > > that extends applications into web and mobile
> > media. Attend the live
> > > webcast
> > > and join the prime developer group breaking into
> > this new coding
> > > territory!
> > >
> >
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
> > > _______________________________________________
> > > Vectorlinux-devel mailing list
> > > Vec...@li...
> > >
> >
> https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
> > >
> >
>
>
> Robert Lange
> vec...@ya...
> http://www.vectorlinux.com
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Vectorlinux-devel mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
>

Re: [Vectorlinux-devel] 64-bit Linux and Kernel 2.6.16

[Tony B. <tb...@gm...>]

Robert - all you have to do on VL is upgrade udev and go with the
2.6.16kernel and it will work.  All the other stuff he has is fine but
not needed.

Hotplug will still be needed for ISA PNP stuff so we should ask on install
if they have any old lagacy isa cards.  If they don't, then straight udev
will work perfectly for them.



On 3/22/06, Robert Lange <vec...@ya...> wrote:
>
>
> --- Tony Brijeski <tb...@gm...> wrote:
>
> > On 3/21/06, Vanger <fa...@gm...> wrote:
> > >
> > > > Kernel 2.6.16 is out.  Lets all try it out and
> > see if we can do the
> > > uevent
> > > > udev thing instead of hotplug and udev together.
>
>
> Here is a link I found for implementing the new udev
> on slack based systems. This requires at least the
> kernel 2.6.15 to work and 2.6.16 came out yesterday.
> This may require a bit of hacking to run nicely on
> vector but it's a start.........:)
> Cheers,
> Vec
> http://piterpunk.info02.com.br/extra/
>
>
> > > Just downloaded, will try.
> > >
> > > > Anyone who tries to say 64-bit is much better
> > than 32-bit probably
> > > doesn't
> > > > know what they are talking about and are just
> > going along with AMD and
> > > Intel
> > > > hype about 64-bit.
> > > Well, the kernel compiles on Slamd64 in about 1.5
> > times faster, then
> > > on VL. But that does not overweight the libraries'
> > troubles.
> >
> >
> > Kernel compiles will be faster due to the 64 bit
> > registers but overall speed
> > is not much different.  There is some difference
> > with 64 bit native apps but
> > not enough to justify losing the ease of use of 32
> > bit distros.  32-bit apps
> > run the same on 64 as they do on 32 unless they
> > heavily use peripherals via
> > the kernel which would speed them up a bit as well.
> >
> > > My Sempron 2800+( 1.6 Gig but
> > > > overclocked to 2.0 gig 200fsbX10) socket 754 cpu
> > on the k8n mobo
> > > How did you do it? 2800+ has locked multiplier 8x.
> >
> >
> >
> > My mistake - lol.  I meant to write 250x8 for 2.0
> > Gig.  Yes the x86_64 cpus
> > are multiplier locked.  My mobo allows me to raise
> > the cpu fsb independant
> > of agp and memory speed.
> >
> > > runs about the same as my old AthlonXP 2400+(2.0
> > Gig
> > > Well, usual system tasks are nearly the same. When
> > you are doing some
> > > math and optimise the program for your
> > architecture, K8 performs
> > > really better, then K7.
> >
> >
> > Yes but there are very few applications that take
> > full advantage of the
> > 64-bit architecture at this time.  Some have been
> > rewritten to include the
> > 64 bit registers but not as optimized as they should
> > be.  They are basically
> > ports of 32 bit.  This will hopefully change in the
> > future.
> >
> > I'm going to give Kanotix 64 a shot this evening
> > which is just debian 64 but
> > I will also have to setup a 32-bit chroot
> > environment for it or try the
> > ia32-libs install to see if that works for 32 bit
> > apps.
> >
> > I don't think simply installing a kernel that is
> > x86_64 optimized would do
> > anything without using a 64-bit compiler and
> > recompiling all libraries that
> > have 64-bit ports.
> >
> > If VL goes 64-bit, it would have to be total 64-bit
> > with 32 bit libs for
> > those apps that won't compile under 64 bit.
> >
> >
> >
> -------------------------------------------------------
> > > This SF.Net email is sponsored by xPML, a
> > groundbreaking scripting
> > > language
> > > that extends applications into web and mobile
> > media. Attend the live
> > > webcast
> > > and join the prime developer group breaking into
> > this new coding
> > > territory!
> > >
> >
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
> > > _______________________________________________
> > > Vectorlinux-devel mailing list
> > > Vec...@li...
> > >
> >
> https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
> > >
> >
>
>
> Robert Lange
> vec...@ya...
> http://www.vectorlinux.com
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D110944&bid=3D241720&dat=
=3D121642
> _______________________________________________
> Vectorlinux-devel mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
>

Re: [Vectorlinux-devel] 64-bit Linux and Kernel 2.6.16

[Robert L. <vec...@ya...>]

--- Tony Brijeski <tb...@gm...> wrote:

> On 3/21/06, Vanger <fa...@gm...> wrote:
> >
> > > Kernel 2.6.16 is out.  Lets all try it out and
> see if we can do the
> > uevent
> > > udev thing instead of hotplug and udev together.


Here is a link I found for implementing the new udev
on slack based systems. This requires at least the
kernel 2.6.15 to work and 2.6.16 came out yesterday.
This may require a bit of hacking to run nicely on
vector but it's a start.........:)
Cheers,
Vec
http://piterpunk.info02.com.br/extra/


> > Just downloaded, will try.
> >
> > > Anyone who tries to say 64-bit is much better
> than 32-bit probably
> > doesn't
> > > know what they are talking about and are just
> going along with AMD and
> > Intel
> > > hype about 64-bit.
> > Well, the kernel compiles on Slamd64 in about 1.5
> times faster, then
> > on VL. But that does not overweight the libraries'
> troubles.
> 
> 
> Kernel compiles will be faster due to the 64 bit
> registers but overall speed
> is not much different.  There is some difference
> with 64 bit native apps but
> not enough to justify losing the ease of use of 32
> bit distros.  32-bit apps
> run the same on 64 as they do on 32 unless they
> heavily use peripherals via
> the kernel which would speed them up a bit as well.
> 
> > My Sempron 2800+( 1.6 Gig but
> > > overclocked to 2.0 gig 200fsbX10) socket 754 cpu
> on the k8n mobo
> > How did you do it? 2800+ has locked multiplier 8x.
> 
> 
> 
> My mistake - lol.  I meant to write 250x8 for 2.0
> Gig.  Yes the x86_64 cpus
> are multiplier locked.  My mobo allows me to raise
> the cpu fsb independant
> of agp and memory speed.
> 
> > runs about the same as my old AthlonXP 2400+(2.0
> Gig
> > Well, usual system tasks are nearly the same. When
> you are doing some
> > math and optimise the program for your
> architecture, K8 performs
> > really better, then K7.
> 
> 
> Yes but there are very few applications that take 
> full advantage of the
> 64-bit architecture at this time.  Some have been
> rewritten to include the
> 64 bit registers but not as optimized as they should
> be.  They are basically
> ports of 32 bit.  This will hopefully change in the
> future.
> 
> I'm going to give Kanotix 64 a shot this evening
> which is just debian 64 but
> I will also have to setup a 32-bit chroot
> environment for it or try the
> ia32-libs install to see if that works for 32 bit
> apps.
> 
> I don't think simply installing a kernel that is
> x86_64 optimized would do
> anything without using a 64-bit compiler and
> recompiling all libraries that
> have 64-bit ports.
> 
> If VL goes 64-bit, it would have to be total 64-bit
> with 32 bit libs for
> those apps that won't compile under 64 bit.
> 
> 
>
-------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a
> groundbreaking scripting
> > language
> > that extends applications into web and mobile
> media. Attend the live
> > webcast
> > and join the prime developer group breaking into
> this new coding
> > territory!
> >
>
http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
> > _______________________________________________
> > Vectorlinux-devel mailing list
> > Vec...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
> >
> 


Robert Lange
vec...@ya...
http://www.vectorlinux.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Vectorlinux-devel] 64-bit Linux and Kernel 2.6.16

[Tony B. <tb...@gm...>]

On 3/21/06, Vanger <fa...@gm...> wrote:
>
> > Kernel 2.6.16 is out.  Lets all try it out and see if we can do the
> uevent
> > udev thing instead of hotplug and udev together.
> Just downloaded, will try.
>
> > Anyone who tries to say 64-bit is much better than 32-bit probably
> doesn't
> > know what they are talking about and are just going along with AMD and
> Intel
> > hype about 64-bit.
> Well, the kernel compiles on Slamd64 in about 1.5 times faster, then
> on VL. But that does not overweight the libraries' troubles.


Kernel compiles will be faster due to the 64 bit registers but overall spee=
d
is not much different.  There is some difference with 64 bit native apps bu=
t
not enough to justify losing the ease of use of 32 bit distros.  32-bit app=
s
run the same on 64 as they do on 32 unless they heavily use peripherals via
the kernel which would speed them up a bit as well.

> My Sempron 2800+( 1.6 Gig but
> > overclocked to 2.0 gig 200fsbX10) socket 754 cpu on the k8n mobo
> How did you do it? 2800+ has locked multiplier 8x.



My mistake - lol.  I meant to write 250x8 for 2.0 Gig.  Yes the x86_64 cpus
are multiplier locked.  My mobo allows me to raise the cpu fsb independant
of agp and memory speed.

> runs about the same as my old AthlonXP 2400+(2.0 Gig
> Well, usual system tasks are nearly the same. When you are doing some
> math and optimise the program for your architecture, K8 performs
> really better, then K7.


Yes but there are very few applications that take  full advantage of the
64-bit architecture at this time.  Some have been rewritten to include the
64 bit registers but not as optimized as they should be.  They are basicall=
y
ports of 32 bit.  This will hopefully change in the future.

I'm going to give Kanotix 64 a shot this evening which is just debian 64 bu=
t
I will also have to setup a 32-bit chroot environment for it or try the
ia32-libs install to see if that works for 32 bit apps.

I don't think simply installing a kernel that is x86_64 optimized would do
anything without using a 64-bit compiler and recompiling all libraries that
have 64-bit ports.

If VL goes 64-bit, it would have to be total 64-bit with 32 bit libs for
those apps that won't compile under 64 bit.


-------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Vectorlinux-devel mailing list
> Vec...@li...
> https://lists.sourceforge.net/lists/listinfo/vectorlinux-devel
>

Re: [Vectorlinux-devel] 64-bit Linux and Kernel 2.6.16

[Vanger <fa...@gm...>]

> Kernel 2.6.16 is out.  Lets all try it out and see if we can do the ueven=
t
> udev thing instead of hotplug and udev together.
Just downloaded, will try.

> Anyone who tries to say 64-bit is much better than 32-bit probably doesn'=
t
> know what they are talking about and are just going along with AMD and In=
tel
> hype about 64-bit.
Well, the kernel compiles on Slamd64 in about 1.5 times faster, then
on VL. But that does not overweight the libraries' troubles.

> My Sempron 2800+( 1.6 Gig but
> overclocked to 2.0 gig 200fsbX10) socket 754 cpu on the k8n mobo
How did you do it? 2800+ has locked multiplier 8x.

> runs about the same as my old AthlonXP 2400+(2.0 Gig
Well, usual system tasks are nearly the same. When you are doing some
math and optimise the program for your architecture, K8 performs
really better, then K7.

[Vectorlinux-devel] 64-bit Linux and Kernel 2.6.16

[Tony B. <tb...@gm...>]

Kernel 2.6.16 is out.  Lets all try it out and see if we can do the uevent
udev thing instead of hotplug and udev together.

Do a make odlconfig and it should offer you the new uevent options to
configure.  Any issues, let me know.


64-bit Linux.  I just upgraded my main box to a 2800+ sempron socket 754 on
an asus k8n mobo.  VL SOHO 5.1.1 runs beautifully on it.  I also attempted
to do SuSE 10.0 Eval DVD and while it boots up fast, 3d gaming is worse tha=
n
on a 32-bit like SOHO.

If anyone asks about 64-bit on the forum, send them my way.  Right now ther=
e
is a library issue between 32 and 64 bit and it isn't easily fixed as the
big distro guys are each doing their own thing to take care of it.  Most ar=
e
putting 64 bit libs in /lib64 and 32 bit libs in /lib. Fedora only has /lib
and they symlink /lib64 to it so they have a worse fiasco with cross lib
stuff.  I did notice a very slight speed difference between SuSE 10 and VL
SOHO 5.1.1 with SuSE being just a tad faster since it was all 64-bit but th=
e
difference is not enough for me to think about running SuSE as a serious
contender to SOHO.  I will be staying with SOHO 5.1.1 in 32-bit mode on my
system for some time to come and that seems to be the consensus on most
discussions about this.  64-bit, although it has been supported by Linux fo=
r
a long time now, is still in its early infancy on the desktop and I don't
feel the need to bother with a 64-bit port of VL for some time to come.

Anyone who tries to say 64-bit is much better than 32-bit probably doesn't
know what they are talking about and are just going along with AMD and Inte=
l
hype about 64-bit.  This is not to say that it won't change but every app
has to be ported to take advantage of 64-bit registers and then it will be =
a
viable alternative to 32-bit linux.  My Sempron 2800+(1.6 Gig but
overclocked to 2.0 gig 200fsbX10) socket 754 cpu on the k8n mobo with 1 gig
single channel ddr400 runs about the same as my old AthlonXP 2400+(2.0 Gig
overclocked to 200fsbx10) socket A on an Abit NF7S-2.0 mobo with 1 gig dual
channel ddr400.   The old 32-bit cpu's can't take advantage of dual channel
anyway as the cpu has a single memory pipeline so the motherboard and
chipset does all the dual to single translation for it.

Anyway, if you are thinking of upgrading right now I would wait until you
can get at least an Athlon64  4000+ or higher socket 939 cpu which uses tru=
e
dual channel memory bandwidth especially if you already have at least an
AthlonXP or P4.  If you have a P3 or regular athlon, then it isn't a bad
upgrade right now as the prices of the socket 754 and 939(lower end 64-bit
cpus) are very good.  I am happy with my purchase for the money I spent but
it isn't necessary at this time unless you are coming from a P3 or regular
Athlon.

Regards,
Tony