Lighthouse 64 5.14.2 Beta 4

[meeki]

Its rather simple to keep a clean install of any puppy / image based save file.

When you install puppy to flash or hdd, etc. after you save your pup reboot in pfix=ram
Save a copy of your save file and name it backup1 or what ever. Then as you play around with the os save all your documents outside the pup save. Then when you find another chunk of software you like and want to add or keep go back and add your pup save backup file to the boot DIR and boot from it and and the new software and then back that up like you did at the start. Its also good to have a backup of your pup save file encase of a failure.

[RandSec]

Sorry, but I think you are way off base here.

I respect all that each has reported on viruses, here. But this is about LH64 versus in-depth virus discussion. And, thus far, I am not aware of any reports where LH64 has been influenced by malware.

In the old days, malware commonly exposed itself and was easy to find. Some people have always comforted themselves with the idea that if malware did not jump up and hit them in the nose, it obviously did not exist. That was false reasoning then, and particularly false now. Not finding something is not the same as it not existing.

Modern bot malware often hides until a banking transaction is noticed and then exploited. Rootkits often prevent the file system from seeing malware files, and even return the original contents for changed files. Modern scanning software is essentially useless because polyphonic malware commonly "encrypts" itself under a local key. In general, other than in explicitly instrumented systems, no tool or set of tools exists which can guarantee to find malware. That means anybody can have malware and not know, and we only need look to Microsoft Windows users to see that effect in action.

In the old days, malware was typically differentiated as viruses, or worms, or trojans by delivery path, but nowadays those terms are generally more deceptive than useful. Modern malware can and often does embody all these forms and more in a single attack package, so then what do we call it? We now call it malware.

All of security involves predicting potential problems, and then solving them, hopefully before they are costly. Which of course ideally means *before* the problems are exploited in the wild or ever noticed. Waiting until *after* security problems are noticed, as Microsoft has done, is no success at all. Nobody should encourage doing that.

Malware is not generally a Linux problem, but the reason it is not is not because Linux is better designed or has fewer errors. The reason Linux has less malware is that malware writers make less money from code designed to execute in Linux. The popularity of Microsoft Windows thus makes Linux less risky. However, *less* is not the same as *zero*. Those who seek computing security beyond that provided by the Microsoft combine should be welcomed in the mix which is Linux.

Hope the link is met with understanding. And, it offers a wider appeal to getting answers-views at that thread than we would get here on this thread.

Understanding? Not so much.

The discussion on this thread was directly related to the Lighthouse64 issues and bugs which I reported, Some of these, related to DVD-load operation, were deflected or dismissed with the observation that a frugal install on a USB flash drive would make more sense. Since I do not agree, I chose to address that claim by discussing the issues which make a flash install less than ideal, thus presenting DVD-boot as the superior solution. That obviously makes *this* the correct place to discuss those issues. *This* is the place for developing those views through discussion and argument, for those who wish to do so.

Anyone who would prefer to talk about something else, somewhere else, should do so. Anyone seeing useless comments here should feel free to skip them. Anyone who considers this discussion worthwhile might link to it from other threads. But nobody should try to impose on others what to discuss or where to do that.

[Q5sys]

Hope the link is met with understanding. And, it offers a wider appeal to getting answers-views at that thread than we would get here on this thread.

I actually was considering starting a new thread tonight when I got home from work after I saw the conversation continuing, but since RandSec has pretty much stated he wants to comment here, I'll keep it here until TazOC requests otherwise. (it is his thread afterall, and honestly I would like his input on a few things)

I indeed do have both a USB flash with write-enable switch, and a USB card reader which I use with SD cards which have "switches." Neither is satisfactory for malware security.

Can you provide any more information other than 'Neither is satisfactory for malware security.'? I've never heard anyone else say this, so I'm wondering what logic is behind your opinion.

It seems to me that Puppy actually does insist that a flash boot-drive NOT BE REMOVED. (This would be a case of, as TaZoC would say: "It isn't designed, I think to do what you have in mind...") For the case where we boot from a flash drive which really is write-disabled, we CAN, nevertheless, expect to remove the drive without file structure damage, and I have in fact done this. So far so good, but that also means there is no saving to the Puppy save file, and no updates.

There IS the a way to update the system. You simply reboot offline with write-enabled drive, remaster the L64-514.sfs file with whatever programs/setting then reboot with write-disabled. Seriously how often are you adding new programs to your system? For the most part arent most peoples systems stagnant as far as programs and only change with personal documents and program temp files. Yes that may be a bit of work, but if rebooting a system is to much work to securely install a new program, then clearly convenience is more important than security.

The reason we demand a boot flash write-enable is to handle the case of malware having entered during the session and running in memory. We have no particular reason to imagine that we could detect such a thing. So the problem is that we wish to protect our secure non-volatile store from infection. We do that with a write-enable switch. But as soon as we flip that switch for whatever reason, all our security bets are off.

I dont see why you would want/need to write to the drive in the first place other than to install something new.

As soon as we flip the write-enable switch, the flash drive becomes a hard drive equivalent, and can be infected just like a hard drive. Amidst thousands of tiny data-write LED flashes, there is no way to distinguish a few malware infection operations. Nor is there anything about the resulting data which necessarily imply infection. We do not collect a list of changes made to storage, but only the results, and malware hides amidst a deluge of insignificant change.

There aren't thousands of tiny writes when using a frugal install that runs in ram. The only writes to the drive occur when you are saving the session. This can be triggered by a user or allowed to run at a certain interval. I have my intervaal set so that it never runs unless I either trigger it or shutdown. I COULD also take the extra step in setting my boot usb device to read only and modify the save script to save to another media device so that I can 'check' the saved data before integration into my L64-514.sfs file. Plus, I can do that also by simply looking in /initrd/pup_rw/ to see whats there, to see what may be written during save session action. If I dont see something I like, I can simply remove it and its not written.
ANY changes to the live system are saved there before being written into the 2fs, 3fs, 4fs save file. So any user can quickly check to see what 'possible' naughty information is there before doing so. And before someone says that the usb may be written to other than the save file. On a Frugral there are only a dozen files on the drive. If we are talking about a piece of malware being able to infect one of those, then we are WAY beyond a normal malware infection and are at the point of an APT (pardon the buzzword). A piece of malware on that level would have needed to be custom crafted not only explictly for puppy, but for frugral installs within puppy. And even if someone did do that, I think the massive processor spike as a phantom script rebuilds an SFS file on my system would be more than obvious that something is going on that it shouldnt be.

In contrast, a DVD update "session" appears as a separate directory, and all changes are distinguished and encapsulated there. Any malware infection will be there, and that session can be invalidated.

Now TazOC will have to weigh in on this to answer this question, but I dont believe the mechnism for DVD save sessions is all that different from USB frugal save sessions. I dont believe they are, but he'd know more about the process. The USB save session takes all changes to the ram system which are held in /initrd/pup_rw/ and writes them into the save file. I dont see how this is any different than creating a save file on a DVD to load on the next boot. Furthermore as you have already admitted that regarding malware infection, "We have no particular reason to imagine that we could detect such a thing.". What good is good does encapsulation do if you're not going to step through every change on your system at every save? And if you are going to that extent, why not just custom build your own system the way you want. It seems, in my head at least, to as you say 'prize security'; kinda backwards to use someone elses system that you have not personally compilied and assembled yourself. I'm not implying TazOC is not trustworthy, because i truly believe he is; but if you are using a system you have not built, you have no idea what may already be lying in the system, which renders all your efforts pointless.

It seems to me that "keeping changes" really means "possibly keeping malware." Nothing which executes, or is even potentially executable, can be saved with security, if malware is active. And there is no way to know when malware is active, *unless* one has just done a reboot from non-writable (or difficult-write) store, with simple program updates from trusted sources. A Puppy save file would seem to have limited application in that context.

If you're going to take that outlook though, you should NEVER save any information. You could custom build your system with the programs you want and the settings you desire and run that. That system could be run on a read only flash drive, because you wouldnt ever want to save a session. In the off chance you wanted to change your system you could simply remaster your main SFS file to include whatever program you want to add.

It seems to me that once we get past issues of speed and size, the supposed advantage is an assumed ability to erase the flash. That was possible with old-style flash controllers which did not have to balance usage for multi-level analog storage. Yes, flashies can seem to be erased, but internally the information may not be, and it may be recoverable. So erasing a flash may not be as good as it sounds. At least one can break a DVD.

My comments with that had nothing to do with malware, it was forensic based. And there are methods which can be employed to ensure "specific" bits on a flash drive are overwritten EVEN when with a load leveling system on chip level. They are obtuse, but effective; and it works even for large files themselves. And if we are speaking about forensics... breaking a DVD will do nothing, all the data is still readable. If the Air Force OSI can rebuild a hard drive platter after it was removed from a drive and smashed into tiny pieces with a hammer, I'm sure a broken DVD is no problem at all.

Some of these, related to DVD-load operation, were deflected or dismissed with the observation that a frugal install on a USB flash drive would make more sense. Since I do not agree, I chose to address that claim by discussing the issues which make a flash install less than ideal, thus presenting DVD-boot as the superior solution

I was not deflecting or dismissing your issue with the DVD, I simply did not understand your reasoning for doing so. Asking a question about your chosen avenue of security != dismissing it.
It seems your reasons for feeling DVD > Flash centers around the idle write which you feel would occur on a flash based system. While I have no believe I will ever change your mind on this, I do feel its an issue worth discussing openly so that others may read both of our opinions and come to their own personal conclusions on which they feel is superior.

[tazoc]

RandSec,
Does using the full path /dev/sr0 Burner device: setting work for you in Pburn? I recommend applying that in File -> Preferences -> Burner device -> Save, and then closing and restarting Pburn to make it persistent. You should see

Code: Select all

export BURNDEV=/dev/sr0

in /root/.pburn/pburnrc. That setting is important as it specifies which device is your burner. If you'd like to delve into this further, please visit the Pburn thread. I have made a note to update to the latest version. It could be that other Pups might sometimes allow just sr0, but not currently in Lighthouse64.

In contrast, a DVD update "session" appears as a separate directory, and all changes are distinguished and encapsulated there. Any malware infection will be there, and that session can be invalidated.

I agree, the folders on the DVD are each named according to the date each session was saved and can be skipped from loading with the boot option

Code: Select all

pfix=<n>     Number of saved sessions to ignore (multisession-CD/DVD)

While I value the ideas and opinions expressed, I agree with Gcmartin that the detailed malware/security-themed discussion is getting off-topic, so please use an appropriate thread.

Thank you,
TaZoC

[Q5sys]

While I value the ideas and opinions expressed, I agree with Gcmartin that the detailed malware/security-themed discussion is getting off-topic, so please use an appropriate thread.

Thank you,
TaZoC

As requested, when i get home from work ill make a new thread.

With regards to LHP are the mechinisms you have in place for a dvd session save much different from a frugal install save?
from my understanding the only difference is dvd saves each session in a different folder compared to the single save file.

[tazoc]

With regards to LHP are the mechinisms you have in place for a dvd session save much different from a frugal install save?
from my understanding the only difference is dvd saves each session in a different folder compared to the single save file.

I think the two pupmodes are very different. About the only things they have in common is that they both are Lighthouse / Puppy, and both can save a session.

In PUPMODE 77, saving is only done back to the CD/DVD, and only when you click the Save button, or if you choose yes when asked at shutdown. The session folders each contain individual files, not all combined into one save file. If the power is interrupted, all changed and new files since the last save are lost forever! Unless of course, you intentionally saved or copied them to another media.

Boot up again only uses the DVD, loading each session folder in reverse order, newest first, copying both system files, session files and extra SFS to RAM. Because everything must be copied to RAM from the optical media, boot up can be very slow! Extra SFS can be either in the top level of the DVD or (I think) in a session folder. If a file already exists, the copy only updates files if newer. I experienced a situation where some of the writable files copied from the DVD were coming in read-only, so in L64 all changed and new files except /etc/sudoers are made user writable in RAM. Not the best solution, but it solved the problems I experienced.

BarryK's description here says it better than I can:

So, when you boot Puppy, if tracks are read in reverse order and the latest version of each file copied to your home directory in the ramdisk, what about deleted files? Say you delete a file during one session, that has previously been saved to DVD at the last session, won't it come back again next time you boot? No, Puppy has a mechanism that keeps track of deleted files and this won't happen. However, that does raise an interesting point ... the deleted file is still on the DVD, meaning that every single file that ever existed will be recorded on the DVD, meaning that you have a perfect audit trail of past activity.

If you insert a new blank DVD at shutdown, Puppy will burn the complete Puppy system onto the DVD as well as the session -- real handy if the current DVD is getting a bit "iffy".

See also http://puppylinux.org/wikka/MultiSessionLiveDVD
and http://murga-linux.com/puppy/index.php?f=6

-TaZoC

[gcmartin]

Boot up again only uses the DVD, loading each session folder in reverse order, newest first, copying both system files, session files and extra SFS to RAM. Because everything must be copied to RAM from the optical media, boot up can be very slow! Extra SFS can be either in the top level of the DVD or (I think) in a session folder.

3 things

• Bootup is a CD/DVD/BluRay device speeds...not HDD speeds. But, I boot my 64bit laptop of a regular basis using the DVD. Takes a little more than a minute and a half including save-sessions. On my desktop, its been so long since I rebooted, I cannot remember having booting or what the time was.
• I have done 2 different things with LH64. On my laptop, I had used (and reported) a GROWISOFS command to add an SFS in a session prior to version 514. On my desktop, I had used ISOmaster (included OOTB in LH64) where I added an SFS and it was made into the ISO. Both methods worked when booting LH64 DVDs.

Hope this helps

[tazoc]

I have uploaded an update for L64 5.14, (see below) JavaRE-7u5-x86_64.pet and Opera-12.01-x86_64.pet to Lighthouse Update (Update icon on desktop -> get_updates -> OK.)

Also uploaded JavaRE-7u5-x86_64.sfs and Opera-12.01-x86_64.sfs to
http://www.lhpup.org/sfs/514-x86_64/. These are an alternative to the Java and Opera Pets above.

L64_Update-514u2.pet (Lighthouse64 5.14.2 Update 2) includes the following:

• Updated DrivesManager 1.5, (thanks to Radky and Jim1911 for testing) and the original Pmount-puppy. Either can be launched from the Filesystem Menu, after the package manager has finished. If you have a UDF DVD created in Windows, please see if DrivesManager can mount it now. Mounting a UDF disc from the desktop icon will not work yet, unless it is first mounted from within DrivesManager. The optical drive desktop icon volume labels will now update when X is restarted.
• Menu -> Internet -> Firefox Update Help: dialog to aid in installation of latest Firefox.
• Updated to shared-mime-info-0.90 to improve support for certain file types e.g., WebM video.
• Added WebM support to Muppymplayer (part of the MPlayer SFS)
• Bugfix: SFS-Load L64 Notice dialog text cutoff under large Xfont DPI.
• Refined: shutdown to unmount nfs drives, allow .4fs save file on ext3 host part. (thanks to Jim1911) GKrellM, (thanks to Meeki) extract-pet,tgz,txz,deb,rpm scripts.
• Package Manager: include 64-bit vs. 32-bit notice in welcome dialog.
• Also: sys-info-1.2, report-video-glx-0.9.1, ptiming-LH64-0.8.1, PupMenu 2.8, PupSysInfo 2.1.6, gtkdialog4 (thanks to Thunor, Meeki, Radky, Zigbert.)

Please restart X after the package manager finishes installing this update.

-TaZoC

[meeki]

Funny thing happened with your update..... It broke the LHpup virtual servers.The message dialog came up saying hey there is a new update for LightHouse and a force to the update manager and I found the Backup LHPUP mirror Virtualbox and my puppytune Virtualbox servers not responding to a ping from the network, router, my pc, or the actual server box there on. Though there status showed up good.

Rebooted and ignored the update and the mirror server is up and running again.

I would have caught it sooner but I was over at my neighbors house fixing his old Windows XP computer. I told him "that's it your getting Linuxed." Hes now running LHpup 64 and happy. only thing neg he said was when it first booted and barked at him he stated.."as long as this thing does not get flees were good"

[tazoc]

Here are some more 64-bit apps...

Google Chrome 21.0.1180.75 web browser
SFS: http://www.lhpup.org/sfs/514-x86_64/?C=M;O=D 34M

or Pet: http://www.lhpup.org/update/L64-514/Int ... 6_64-1.pet 47M


...another Adobe Flash Player browser plugin update
http://www.lhpup.org/update/L64-514/Int ... x86_64.pet 6.9M


TrueCrypt-7.1a On-The-Fly Encryption (thanks to Q5sys)
http://www.lhpup.org/update/L64-514/Uti ... x86_64.pet 2.4M

The installer script will disable kernel cryptographic services (in TC) to prevent mount errors. PDF User Guide included.

Tip: Before mounting an encrypted file or device formatted with ntfs, enter:

Code: Select all

-t ntfs

into the 'Mount options' box in TrueCrypt.

-TaZoC

[tazoc]

JavaRE-7u7-x86_64 - recommended security update

SFS: http://www.lhpup.org/sfs/514-x86_64/?C=M;O=D 31M
or Pet: click Update icon on desktop -> get_updates 44M


LibreOffice-3.6.1 SFS...

LibreOffice-3.6.1_64_en-US.sfs - LibreOffice stable (open source productivity suite)
http://www.lhpup.org/sfs/514-x86_64/?C=M;O=D 125M

NLS_LibreOffice-3.6.1_64.sfs - language pack for non-US locales
http://www.lhpup.org/sfs/514-x86_64/?C=M;O=D 360M

...or try this (beta test) LO downloader and SFS builder script by 01micko:
http://www.lhpup.org/update/L64-514/Off ... 17-L64.pet 28K
(Identical to 01micko's except for custom gtkdialog-splash from L64.)

-TaZoC

[Q5sys]

JavaRE-7u7-x86_64 - recommended security update

SFS: http://www.lhpup.org/sfs/514-x86_64/?C=M;O=D 31M
or Pet: click Update icon on desktop -> get_updates 44M


LibreOffice-3.6.1 SFS...

LibreOffice-3.6.1_64_en-US.sfs - LibreOffice stable (open source productivity suite)
http://www.lhpup.org/sfs/514-x86_64/?C=M;O=D 125M

NLS_LibreOffice-3.6.1_64.sfs - language pack for non-US locales
http://www.lhpup.org/sfs/514-x86_64/?C=M;O=D 360M

...or try this (beta test) LO downloader and SFS builder script by 01micko:
http://www.lhpup.org/update/L64-514/Off ... 17-L64.pet 28K
(Identical to 01micko's except for custom gtkdialog-splash from L64.)

-TaZoC

Man you are on top of thigs... I was just about to come post this and ask you if anything special needed to be done to compile it... and here I find you've already gone and done it.
You are freaking awesome!

[Pete22]

I am so happy to see you back. It was Lighthouse that won me away from windows.
I have checked back from time to time, I think I even thought I saw a message from you once,
I thought I had dreamed it. Now I know it's for real.

You asked earlier about using Fatdog's Audio-all-in-one-sfs on Lighthouse
My brother and I got it working beautifully in Lighthouse. If what we did, can be of any assistance
to you please let me know.

I have been using Lighthouse for about four years. One of the things I like so much about LHP is,
you put things in places that were logical to me. I am not a geek, but I looked like one using your work
I also appreciated your personal help in the early days when I could not figure out how to do something,
you kindly made work-a-rounds for me.

Would you please verify that the link provided here to donate funds to you,
is legitimate? I am most willing to contribute.

For a mirror site you might want to contact www.smokey01.com
He has a place on his site for puppy developers.
You can see it here http://www.smokey01.com/devs/

Take extra care of yourself,

Pete

[Q5sys]

Would you please verify that the link provided here to donate funds to you,
is legitimate? I am most willing to contribute.

Pete, If you go to the official LHP site: http://lhpup.org/
Scroll to the bottom and you'll see the yellow Paypal Donate Button. Click that.
It is legit, I've donated before.

[tazoc]

Q5sys and Pete22,

Thank your for the kind sentiments and feedback! Yes, the orange Donate button at lhpup.org -> Tips -> top of page, or bottom of some other pages, allows sending of any amount to me. You can use PayPal or a credit card. If you prefer send a check to me, PM me for the mailing address. I plan to set up a new donations page with my costs, donations YTD, etc. and then link to PayPal from there. I have received a total of $66 from 5 contributors year-to-date. I try to acknowledge donations in a timely fashion via PM or email and very much appreciate each one, regardless of the amount. I realize these difficult economic times limit our budgets.

My health is not 100% but am able to get something done most days. I am working toward a release candidate ISO of Lighthouse64, with some bug fixes and a few new packages.

I am trying to improve language support in L64, but most apps are still en_US only, with the exception of the separate LibreOffice and KDE NLS sfs files. I think Opera and Google-chrome are also localized. Drives Manager and Personalize Settings include partial localization. The next release will include GKrellM and Geany, each with full language support. BarryK, 01micko, Shinobar and others are making great strides in this area and I will try to incorporate their work as time allows.

Best regards,
TaZoC

[meeki]

Hey every one Looks like I got Skype all sorted out. Its a combination of Slackware libs, Crunch Bang fix etc. Basically others in the Linux community did all the hard work I just parted it together for us and fix some depends and a window wrapper issue.

If you have a bug let me know PLZ but as of now ive been running it for 3 weeks and now only 1 week with out issue. I feel its safe for release.

Skype 4.0.0.7
Skype-LH64-4.0.0.7.pet
http://dl.dropbox.com/u/12968946/lighth ... .0.0.7.pet

Checksum
Skype-LH64-4.0.0.7.pet.md5
http://dl.dropbox.com/u/12968946/lighth ... .7.pet.md5

Notes:

If you get a bug when you click the chat window all you have to do is move it once and it stays fixed. Right click the bottom of the chat window and select move. Then with out clicking move your mouse towards the bottom right of your screen and the container will stay around it for now on.



Up next - fix drop box. I think i have it fig out with LD_PRELOAD=

[/img]

[meeki]

great work tazoc.

Great to hear your doing better.

About donating. I agree times are hard I have not donated much myself.

Its not all about the amount you donate. Your time and knowledge can go a long way supporting the Linux OS you use.

If you fix something, compile something because its not in the pets/sfs/etc. POST IT! odds are someone else needs it too.

Its this awesome community of basic enthusiasts to coding experts (not me ) that keep something like this alive and well.

Keep pecking every one!

[Q5sys]

I have received a total of $66 from 5 contributors year-to-date. I try to acknowledge donations in a timely fashion via PM or email and very much appreciate each one, regardless of the amount. I realize these difficult economic times limit our budgets.

Thats it? That's going to have to be remedied. Expect something in the next few weeks.

My health is not 100% but am able to get something done most days. I am working toward a release candidate ISO of Lighthouse64, with some bug fixes and a few new packages.

Mind a few requests? Only worry about them if you have time.
1) Slightly newer Kernel
2) Slightly newer Glibc version

There are 2 other things I think would be amazing, but I know will take time. I'm willing to compensate you for your time. So they could be paying side projects when you have time to work on them.
1) KDE 4.9 would be epic.
2) If Im unable to make gnome3.4 work with LHP, then I'd be willing to drop some $ to make it happen.

I'm still trying to work on getting gnome ported over to lighthouse but I cant seem to manage it. I've gotten some help from one of the other guys in the forum, but I cant get gnome3 to load and run for more than 30 seconds before crashing to a halt.

So if I continue to hit a roadblock with that I'm going to see about cranking out the 4.1 version of XFCE and the latest LXDE apps.

[meeki]

Hey thought id share the pet.

Glade is "A User Interface Designer" (http://glade.gnome.org/).

"What is Glade?

Glade is a RAD tool to enable quick & easy development of user interfaces for the GTK+ toolkit and the GNOME desktop environment.

The user interfaces designed in Glade are saved as XML, and by using the GtkBuilder GTK+ object these can be loaded by applications dynamically as needed.

By using GtkBuilder, Glade XML files can be used in numerous programming languages including C, C++, C#, Vala, Java, Perl, Python,and others." (http://glade.gnome.org/)



I like it because you can also insert little bash scripts or bash programs. Make a button and point it to a SH but it can do allot more than that! I like it for making a GUI for all the command line code or scrips I write.

The pet is for GTK+2 ( i think LightHouse is using GTK+3 ) so it should work up the version changes.

Here is a tutorial I found that give you a quick Idea of what your using it for
http://youtu.be/3JuvSobjMi4

Why you should use this while using GTK dialog for writing a GUI for bash commands in Puppy:
for the most part you can avoid compiling constraints. If you write it to work in puppy its going to work most the time for all puppys. If its not working its because your calling a program that is not installed on that puppy but its EZ to write a check in SH file to see if its installed and then send a Dialog to the user to install that program.

Glade pet
Glade-LH64-3.8.2.pet
http://dl.dropbox.com/u/12968946/lighth ... -3.8.2.pet

meeki

[tazoc]

Request to all contributors: If you get something compiled, before posting, please don't forget the NLS (Native Language Support) files, often found at /usr/share/locales. (Instead of typing make install, type: new2dir make install, then in Step 3, use option 3. This makes it easy to separate them out so that en_US users don't need to download them, while others can.) I really want to make Lighthouse as user-friendly as possible, regardless of locale or native tongue. Even though I've often neglected language support in prior releases, it is now important to me!

Translators can help also. I plan to work on incorporating NLS tools like MoManager in the future.

Thank you for your consideration.

Mind a few requests? Only worry about them if you have time.
1) Slightly newer Kernel
2) Slightly newer Glibc version

I would like these also, however it's been a long time since last Beta release, so I want to get this 5.15 RC/final out without extensive core changes before working on another Alpha/Beta. The current L64 5.1x aligns with glibc-2.13 from Slackware64 13.37 for improved compatibility with their repos.

There are 2 other things I think would be amazing, but I know will take time. I'm willing to compensate you for your time. So they could be paying side projects when you have time to work on them.
1) KDE 4.9 would be epic.
2) If Im unable to make gnome3.4 work with LHP, then I'd be willing to drop some $ to make it happen. I'm still trying to work on getting gnome ported over to lighthouse but I cant seem to manage it. I've gotten some help from one of the other guys in the forum, but I cant get gnome3 to load and run for more than 30 seconds before crashing to a halt.

1) I plan to update KDE for L64 6.xx later. It will likely need glibc-2.15 as well as Qt-4.8.2 and other core updates. Slackware64 14.0 final with glibc-2.15 is getting closer to a release, and that will help me with the latest KDE4 for L64 6.xx later on.
2) Gnome has some vexing dependencies and I couldn't even get Gnome-Games-3.0.1.1 to work properly in L64! I'm afraid I won't be much help with that request.

So if I continue to hit a roadblock with that I'm going to see about cranking out the 4.1 version of XFCE and the latest LXDE apps.

Sounds good. I appreciate the assistance, Q5sys.

Thanks again,
TaZoC