Kernel 2.6.17 (Puppy2)

[MU]

http://puppylinux.com/news.htm


This is real good news, as I could not use Puppy2 seriously due to the unionfs-bug until now...
Mark

[kirk]

Amen brother. This will also take care of that nasty unionctl bug that was fixed a few months ago, now we should be able to add and remove file systems from the union from within the union. Getting excited about puppy2 again.

[wscarl]

Puppy 1( 2.4 kernel) Should Be conitued,by a puppylinux-foundation team, as long as there are new versions of 2.4 kernel. While Barry leads the Puppy2 (2.6 kernel) team.

[Nathan F]

Oh fantasic! I was thinking along the same lines because of the unionfs issues.

Nathan

[klhrevolutionist]

That is great news!! Great job!

[gnomen]

Is NTFS write support through captive a possibility? I presume NTFS is only an issue where there is a working, or not so working, windows installation allready present

[Flash]

Captive seems awfully large to include in Puppy. It's around 12 MB.

[Melmo]

Another advantage (though not sure of the size) is that kernal 2.6 is compatable with udev, meaning puppy could have hotplug.

I.e. portable media such as digital camera's and USB drives could be plugged in and automatically mounted W/O the need for MUT.


More windows/OSX like =)

[Pizzasgood]

Hotplug=speedy. Hotplug=easy. Speedy+easy=Good_Puppy. Good_Puppy=Happy_Pizzasgood

That also means one less icon would be needed on the desktop, which would definately please some people.

[Melmo]

Pizzasgood,

Just re thinking that one im not so sure that removing mut is such a brilliant idea, it certainly has its uses, specially since it gives easy access to all drives on the system without having to know where they are mounted, or what they are mounted as.

[Lobster]

Home (Rox) Mut and Console could all be combined to one icon / option?

Console would be easy in fact "xterm here" is already in Rox
However Rox is written in C? and Mut in Script?

Most people are not accessing drives but files and "Home" might be called "files" with icons for drives and console

Yep I suggest we create a Puppy specific fork of Rox - I heard it is going peculiar in its future development? Is Rox development an option for anyone?
Perhaps I just need to change my medication?

Rox - so good it Roxs

[BarryK]

Lobster,
I have thought about that too, re Rox. My thinking is that someone should take
the version we are using, 1.2.2 (I think, from memory), then get it to run on GTK2, or leave it at GTK1 and use Xft to get antialiased fonts.
After that, can pick out a few of the nice features from later versions.

Actually, adding Xft can't be too hard. That patch of Dillo that MU has worked on for PB-Debianinstaller uses Xft, and the author wot did it also patched some other apps with Xft to make them have antialiased fonts.
Where's that url, ah here:
http://teki.jpn.ph/pc/software/index-e.shtml

[Nathan F]

IN answer to Lobster's idea, it would be relatively easy to create a desktop icon that can launch all of those programs, via a right click menu. Or to create a wrapper script for them. I'd personally rather not combine the console with the filer, but it might make sense to combine the drive mounter and filer icons. Might, might not. The way I did it in Grafpup was to create a rox wrapper that allows you to choose which drive mounter you want to use, which I think is useful since I have drives that are only visible to one or the other on my system. I suspect I may not be alone on this among people with newer hardware, especially the various frontside flash readers and ports that have become common recently.

Now on to my feelings about ROX. I'd be happy if the latest version could run the pinboard without turning on it's background setter. As it is this causes all kinds of problems for people who want to run it alongside applications that use transparency, like aterm, or Fluxbox, or worse yet Torsmo and some Enlightenment effects. I'd love to see someone create a more sensible branch of ROX. I'm not a big fan of GTK2, though.

Since Dillo was mentioned I'll point out that the project is currently in the middle of porting over to FLTK, which is a much lighter and faster toolkit than GTK2. There are other applications that are following suit, most noteably Cinepaint is due to release an FLTK port by months end. There is also an effort underway to create a lightweight desktop environment based on it, and it looks as if the project will get there. They already have a very interesting looking WM and quite a few applets and smaller programs like clocks and calculators. GTK1 is obviously not being developed at all anymore, not even bugfixes, so it makes a lot of sense to use a newer and supported toolkit.

Of course porting any application from one toolkit to another involves major work, so it may not be a project that anyone here wants to take on.

Nathan

[Pizzasgood]

Would it maybe be easier to hack the new Rox rather than the old one? Transplant the old pinboard into the new Rox, and we'd really be rockin'.

if the latest version could run the pinboard without turning on it's background setter.

Does that mean we can deactivate it, but we have to disable the pinboard also? Perhaps a superior desktop could be found?

Maybe we could replace it with a giant CLI, with icons, clock, toolbars, etc. on the sides/top/bottom. Maybe give it a simple background image too.

[GuestToo]

this causes all kinds of problems for people who want to run it alongside applications that use transparency, like aterm, or Fluxbox, or ...

as a workaround, if all of the wallpapers are set to the same pic at the same time, it usually works ok, and users are not confused ... it's when different apps are each setting their own backgrounds that things can get confusing ... something like Pizzasgood's universal-background-setter might be a useful workaround

i don't know if there's any way to disable Rox's background setter, other than hacking the source ... i did hack Rox's source slightly for my package, to remove the "Running As Root" line from the top of the Rox window

[Nathan F]

I've been following MU's progress on the new background setter closely, and it looks as if he's found a workable solutionfor now. The latest version should be able to do basically what MoBetta did (in a slightly different way) and just make the two backgrounds agree. It's not perfect, but it's good enough to use now. There are only a few times where I can see it becoming a problem, and that involves running a ROX pinboard with certan things that require advanced transpaency effects, like the flame at the screen bottom in enlightenment.

I'm a complete novice at C myself, but I've managed to hack the ROX source to give an 'Open With..' menu in 2.4, just like we have in 1.2. I'm also thinking I might remove the background menu entry since MU's program should be used for it. I'd like to just disable the background altogether but don't know how to so it (yet, but I'm a pretty determined guy). That would be the ultimate solution.

Actually, I think it's high time someone branched off the ROX sourcecode in a more sensible direction.

Nathan

[tempestuous]

The 2.4 kernel is fine for all of my hardware, but it's clear that some newer devices and projects will be made possible with the move to 2.6. TV tuners, for example, are supported under 2.4 with the v4l and v4l2 drivers, but some newer digital TV tuners will only work with the more modern V4L-DVB drivers under 2.6. So the 2.6 kernel will open the door for Puppy-based digital TV/personal video recorder projects.

Barry, I suggest that the DVB (TV tuner) modules in the kernel config are probably not needed by enough users to deserve being included in Puppy2, and even then, some TV tuners require specially patched versions of these modules, anyway.
But to support such modules as later add-on packages, it would be good to have this in the kernel config -

CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
CONFIG_VIDEO_DEV=m

Once you have finalised the kernel setup, I look forward to obtaining your kernel source.

[slvrldy17]

We also need support in the kernel for the network and sound chipsets from Nvidia and possibly others - the modules that Tempestuos derived from the Nvidia linux driver will only work up to puppy 1.0.8r1 - I'll try them on puppy 1.0.9 when I get home from work later.

[BarryK]

Here are the current settings:

Code: Select all

# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_CHARDEV=m
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=m
CONFIG_I2C_ALGOPCF=m
# CONFIG_I2C_ALGOPCA is not set
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
CONFIG_I2C_ELEKTOR=m
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
CONFIG_I2C_ISA=m
# CONFIG_I2C_NFORCE2 is not set
CONFIG_I2C_PARPORT=m
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set

#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_RTC_X1205_I2C is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#

#
# Video Adapters
#
# CONFIG_VIDEO_ADV_DEBUG is not set
CONFIG_VIDEO_BT848=m
CONFIG_VIDEO_SAA6588=m
CONFIG_VIDEO_PMS=m
CONFIG_VIDEO_BWQCAM=m
CONFIG_VIDEO_CQCAM=m
CONFIG_VIDEO_W9966=m
CONFIG_VIDEO_CPIA=m
CONFIG_VIDEO_CPIA_PP=m
CONFIG_VIDEO_CPIA_USB=m
CONFIG_VIDEO_SAA5246A=m
CONFIG_VIDEO_SAA5249=m
CONFIG_TUNER_3036=m
CONFIG_VIDEO_STRADIS=m
CONFIG_VIDEO_ZORAN=m
CONFIG_VIDEO_ZORAN_BUZ=m
CONFIG_VIDEO_ZORAN_DC10=m
CONFIG_VIDEO_ZORAN_DC30=m
CONFIG_VIDEO_ZORAN_LML33=m
CONFIG_VIDEO_ZORAN_LML33R10=m
CONFIG_VIDEO_MEYE=m
CONFIG_VIDEO_SAA7134=m
# CONFIG_VIDEO_SAA7134_ALSA is not set
# CONFIG_VIDEO_SAA7134_OSS is not set
CONFIG_VIDEO_MXB=m
CONFIG_VIDEO_DPC=m
CONFIG_VIDEO_HEXIUM_ORION=m
CONFIG_VIDEO_HEXIUM_GEMINI=m
CONFIG_VIDEO_CX88=m
# CONFIG_VIDEO_CX88_ALSA is not set
CONFIG_VIDEO_EM28XX=m
CONFIG_VIDEO_OVCAMCHIP=m
CONFIG_VIDEO_AUDIO_DECODER=m
CONFIG_VIDEO_DECODER=m

[tempestuous]

Great, thanks ... but I missed 2 other important settings -

CONFIG_DVB=y (DVB For Linux)
CONFIG_DVB_CORE=m (DVB Core Support)

"CONFIG_DVB_CORE=m" is not so important, we can just add that module any time later, but "CONFIG_DVB=y" is crucial. This option can only be enabled within the kernel, not as a separate module.


slvrldy17, the nVidia-sourced nvnet.o module is somewhat non-standard, and probably should be considered "add-on".
The Broadcom b4400 and tg3 modules fall into this category, too.

Regarding a sound driver for nForce, the nvsound.o module I initially compiled for stlchuck is OSS, and this should be considered a workaround.
More recently I hacked the ALSA snd-intel8x0.o module for Knoc so it would work with nForce - http://www.murga.org/~puppy/viewtopic.php?t=7378
If you, stlchuck, or Knoc could confirm that this modified ALSA module works, then perhaps Barry might consider including it in Puppy2, since it's an update of an existing module.