rc1 is approaching (hoping to release it within two weeks) so its a time to answer wishes thread.
"I wish Pantheon desktop environment for Porteus"
this rather wont happen. Ahau left the project and we have to spread all the workload involved in modules maintenance between me and Jay. Two devs must maintain 4 desktops x 2 archs - that's enough i think.
"My first wish is to create data directory next to changes, so it could be only selected (symlinked) changes persistent (even on nfts/fat) ... Then it could be created for example never broken (sdxY) symlink "/home/guest/Desktop" to "/mnt/data/guest-saved/Desktop""
we have 'magic folders' for this - please try them.
"Rebuild way of setting language so it could be option to choose prefered system language/locale while building iso in Porteus Wizard."
agree - this would be great but this is a lot of work and we have LST tool in PSC already which does the job. no point for double maintenance.
"Add option to activate directories (Right Mouse Button) like xzm modules. If that directory contains .posixfs file (permission allowed only on posix filesystems - test for disable NTFS/FAT) then that directory could be activated, or similar solution."
modules are read only - folders are not. if user remove a file directly in that folder (not in the union) then system may become unstable. i'm against.
"Another way of announcing final release - it could be Porteus RCFinal name and if we have not found major bugs during 2-3 days it should be then only renamed to Porteus Final and announced."
2-3 days is bit too less. i think that rc2 will be where the userland gets frozen, kernel (latest 3.17.x) should be ok to upgrade for final.
"from= cheatcode should search porteus directory and porteus parent directory for sgn and base modules (like v1.2) - no subdirectories needed (easier to manage). "
will think about this if wee decide to move everything under /porteus (this is getting awkward as UEFI requires additional /EFI folder in top root on the device)
"If we build xzm modules we must do it on parent (root) directory but sometimes we need only one directory (etc, opt, home/guest) so it would be nice if xzm builder could recognize name - that it has not parent directory and create main sup-directory(ies) while building for: etc, home, (home/)guest, opt, root, usr directory names."
will see what i can do about this
"7. Right Mouse Button option - copy to memory/changes - it would be useful with changes-ro or EXIT: - if we need make modified file/directory persistant -> RMB -> Copy to persistant changes.
The same could be also for deleting files if they exist in persistant changes.
not really see a point of this. this is how it works currently:
you create a file -> it get's kept in RAM -> if you delete it during the same session then it gets removed from RAM -> if you do not delete it then it gets saved on hd during shutdown (RAM works as a buffer which prevents unnecessary writes)
"8. Add vmlinuz, initrd.xz (or vmlinuz-$v-$arch, initrd-$v-$arch.xz) and porteus-$v-$arch.sgn to http://dl.porteus.org/i486/current/
andhttp://dl.porteus.org/x86-64/current/. I think that also vmlinuz and initrd.xz should be moved from syslinux to porteus directory because syslinux is optional and vmlinuz, initrd (and modules) are always required and owned by Porteus."
again - will think about this if we decide to move everything under /porteus
"Add to Firefox prefs.js: "
we can pin there forum and facebook page (not sure about the pastebin.com as users use it only when in troubles)
what does 'no-remote' switch do?
we have at least 5 entries in the bootloader menu (GUI, Always Fresh, Copy2ram, Text, PXE) i dont think we should double them with 64bit kernel options as it would look messy. as you pointed out correctly: it would also cause endless GPU drivers/Vbox confusion (which driver to use with which kernel)
OTOH - porteus.cfg is really easy to customize so you could create such entries yourself.
all what you need to do is to:
a) use vmlinuz64 instead of vmlinuz in 64bit entries
b) drop 000-kernel64.xzm to /base then use 'noload=000-kernel.xz' cheatcode in 64bit entries.
"Adding touchscreen support is my main wish. At least, a virtual keyboard and decent mouse emulation"
virual keyboard will be there (i'll add folrence to Lxqt) and touchscreen support should work ootb for most of the devices
"Native dual-boot support (the same iso to be able to boot automatically from both legacy bios and uefi)."
this is granted - there will be an option in the web wizard to create UEFI ISO. the only downside is that such ISO must be extracted on FAT partition (changes can still be saved on second partition formatted with linux filesystem) due to EFI firmware limitations (it can read only from FAT).
"I would like a debian (ubuntu) or archlinux clone of porteus. Just to show to the world how intelligent is porteus. It could come in only one desktop flavor."
as per my explanation in regards to the Phanteon desktop: i dont think this will ever happen
"I would like to see network support built in or available like printer support. Many/most pcs are connected to others; laptops to desktops, spouse to spouse, parent to kids, work to home, etc."
dont understand. i always thought this possibility is in porteus already?
"Maybe a security module would be useful/desireable, with a firewall and an AV included."
usm could be used to download these
"And I would like to see the number of developers double. The current ones are getting over worked."
devs are coming and are leaving. we cannot invest much time in a training (Porteus is much different from other linuxes and quite complicated due to aufs, modules, etc..) of a person who leaves after a year or two.
i remember recent blog post of the Bodhi project leader who claims that no one from the original Team last till today.
Community section of the forum is for new projects and active devs. if they get some attention and survive over a year (or two) then may get accepted as official flavours.
"1. A version of FireFox that supports signing on to a Linksys Guest account.
I can do it with the FireFox in Porteus 2.1, the FireFox in Porteus 3.0 and in Porteus 3.0.1 when I use the FireFox .xzm file from 3.0."
we do stick to slackware official firefox packages so this bug should go upstream
"2. A network manager that doesn't name duplicate network names with a " 1". ie Linksys and Linksys 1. Renaming the file with a space in it's name has the same result as deleting it, it keeps returning due to .wh. files. The network manager need to assign the duplicate name with a "_1" or "-1" in it's name not a " 1"."
i'm sorry but i do not understand this one. even if i do i probably would not be able to fix this. please fill bug report upstream.
"I would like to move the boot subdirectory under the porteus subdirectory, so that only one subdirectory under the root directory of ISO/USB is needed."
i remember Slax 7 had this feature so it should be possible. will investigate this.
"A virtual keyboard would be much appreciated for a future Porteus"
this is accepted
"Adding PaleMoon as slim, optimized Firefox variant"
rather not as it wont run on older PCs
"stronger encryption for porteussave file,"
added to my TODO list
"I need a new cheatcode 'encr=/path1;/path2;..' that encrypt and mount
partitions and filecontainer in this order path1, path2 and .. with the same password like
porteussave file from 'changes' cheatcode (or if not exist ask separate)."
i'm trying to reduce number of cheats whenever i can (people do not use or even read about them). i'm worrying you would be the only user benefiting from this.
simplest solution is to add the code for mounting encrypted container to rc.local.
thanks a lot for all your feedback given.