Perhaps getting some info from dave on what desktop-session will do/does would be helpful.
It looks to me that many pieces of the desktop-session package (wallpaper app, menu links, desktop-defaults, etc...) are actually stand alone pieces that don't run all the time. So I'm thinking that desktop-session doesn't actually monitor anything, but rather is more of a launcher for the wm.
dave, what are your plans for the desktop-session system?
1. simplifying the configuration (one set of config files)
2. removing desktop-menu from the sequence?
3. are you adding anything?
4. fixing desktop-defaults (which I assume you are doing since it affects antiX-15 users)
5. Is/will desktop-session be anything more than a wrapper around the chosen WM starting? If so, what?
I'm going to admit that many problems I associated with desktop-session on my eeepc are actually a problem in the parallel nature of the boot chain, with slim starting up before the system is actually ready for it. But desktop-session was easy to point a finger at because it is new. and its shows running in htop so the user is left with the conclusion that its doing something. and since its unique to antiX, there is no information available other than a configuration paragraph in the faq.
-
Posts: 2,238
dolphin_oracle - Joined: 16 Dec 2007
-
Posts: 1,445
skidoo - Joined: 09 Feb 2012
#62
ssh server is set to autorun by default, but clipboard manager is not.
Seems like"misplaced priorities" (or something) in the context of a"desktop linux" distro.
Old saw. I've mentioned this previously. I understand that the devs (and some vocal users) consider a clippy manager to be a bloaty, non-essential feature.
Search icon in tray is a standout feature. Neither it nor fxkb adds much session RAM overhead.
Compared to"documenting availability of, and how to enable", autostarting them seems reasonable to me.
It's not difficult for a motivated user to figure out how to disable any unwanted tray autostarted items.
regarding default autostart items:A concerning aspect is that each of them is active by default.
ssh server is set to autorun by default, but clipboard manager is not.
Seems like"misplaced priorities" (or something) in the context of a"desktop linux" distro.
Old saw. I've mentioned this previously. I understand that the devs (and some vocal users) consider a clippy manager to be a bloaty, non-essential feature.
Search icon in tray is a standout feature. Neither it nor fxkb adds much session RAM overhead.
Compared to"documenting availability of, and how to enable", autostarting them seems reasonable to me.
It's not difficult for a motivated user to figure out how to disable any unwanted tray autostarted items.
-
DavePosts: 1,062
- Joined: 20 Jan 2010
#63
Most"parts" are independent but benefit from variables passed on from desktop-session but should work without (the wallpaper app for instance though you would need to write the session code to ~/.desktop-session/desktop-code.[0-9])
The main feature is to open / close window manager and icon manager combinations (or sessions). This can then be done on the fly, without login / logout as well (alternate desktops).
Added then after were the following items (which were also started every session):
- wallpaper app background script (used to be in ~/WM/startup (login_background[.sh] IIRC) I would consider this a"session" thing.
- conky (used to be in ~/WM/startup) I would consider this a"session" thing, some don't so configurable in desktop-session.conf
- a function to see if the"antiX default configuration files" (window manager root menus for example) are more recent (updated in a deb) than the ~/ files and either a: update the user file, b: notify/ask the user of the change, c: completely ignore (disables function)
- a function / script to build xdg compliant environment / startup. As this is default, programs (like clipit / wicd / dropbox) look out for XDG directories (in terminal type"echo $XDG_" and press tab to see some examples) as well as are setup for XDG autostart (/ etc/xdg/autostart). These files are setup in the program debs, therefor they are already there and included in the iso/system. Being already there why not have an option to utilize it.
- a startup file function / hook as why replicate one item you would always want started in any window manager you are in to all the various window manager startups.
- command to set screen blank times, configurable through set-screen-blank (can be independant, but as seen in previous releases needs to be in startup otherwise settings are"forgot")
The items were added to desktop-session for a couple of basic reasons:
- as it would be there for the"alternate desktop" function. Therefor would be central to all window managers and could be uses for"session" related items (XDG / common startup items / etc)
- had potential for greater accuracy in knowing when the window manager was started and handling the"basic startup apps" (wallpaper / conky )starting (to avoid"ghost windows", prevent conky from starting below the icon manager (rox/space), preven the wallpaper from setting before the icon manager was running (Blank grey rox pinboard? ) The delay is set high by default for older computers (p2/3) in desktop-session.conf, you could most probably tune it in better for quicker load times (my laptop/desktop with space-fluxbox can be set to"0" for delay)
It was something thought/talked about followed by a work from BitJam (core startup and shutdow / alternate desktops) and I (added startup / session items).
I was adding the items in an attempt to fix issues that were expressed in the forums about applications having issues without"session variables" (lxappearance / bluetooth for me and some others that I cannot recall), ghost windows, startup lapses (grey emtpy pinboard, volumeicon missing from tray, conky behind icon manager, etc), others.
If it should be decided / viewed as beneficial and therefor worthy to be kept...
1. Yes the user configuration (I admit global vs user was an error in thought on my part)
2. I do not think I put it in... I had it to set only on installation via apt and in the root menu. IIRC anti wanted it in there as on live cd there would be no application menu or it was in the wrong language or something of the sort. My thought on a solution was a first run script you could put all items needed on first run in ( /usr/share/desktop-session/first-run-script). Some things made it there some elsewhere... it could be cleaned up and moved to there as far as I know (it is how I have it on my computers). It does make the desktop load faster for installed (or live with persist). Along with this 'solution' was the requested first run dialog option and the changable text file (/usr/share/desktop-session/first-run-text). Meant to be similar to MX 15 first run help window, but it did not go that far.
3. I would like to continue to add:
- mouse setting loading ( like set-screen-blank configures the screen blank time and is renewed via desktop-session next login )
- keyboard setting loading ( again like set-screen-blank configures the screen blank time and is renewed via desktop-session next login )
- try to setup arandr's export setting so that desktop-session can run it (currently possible by exporting, then adding the resulting script to desktop-session/startup)
- possibly a"save desktop" like xfce has, but this is difficult and I know both BitJam and I have tried to make something (BitJam more than I, I think) and have turned out not so reliable or successful
4. I think this should be done, refer to other thread (post44979.html#p44979)
5. Hmm, maybe? I do not really know, but for the moment it would seem to continue to be a wrapper of sorts.
Yes for the most part you are correct.dolphin_oracle wrote:Perhaps getting some info from dave on what desktop-session will do/does would be helpful.
It looks to me that many pieces of the desktop-session package (wallpaper app, menu links, desktop-defaults, etc...) are actually stand alone pieces that don't run all the time. So I'm thinking that desktop-session doesn't actually monitor anything, but rather is more of a launcher for the wm.
Most"parts" are independent but benefit from variables passed on from desktop-session but should work without (the wallpaper app for instance though you would need to write the session code to ~/.desktop-session/desktop-code.[0-9])
The main feature is to open / close window manager and icon manager combinations (or sessions). This can then be done on the fly, without login / logout as well (alternate desktops).
Added then after were the following items (which were also started every session):
- wallpaper app background script (used to be in ~/WM/startup (login_background[.sh] IIRC) I would consider this a"session" thing.
- conky (used to be in ~/WM/startup) I would consider this a"session" thing, some don't so configurable in desktop-session.conf
- a function to see if the"antiX default configuration files" (window manager root menus for example) are more recent (updated in a deb) than the ~/ files and either a: update the user file, b: notify/ask the user of the change, c: completely ignore (disables function)
- a function / script to build xdg compliant environment / startup. As this is default, programs (like clipit / wicd / dropbox) look out for XDG directories (in terminal type"echo $XDG_" and press tab to see some examples) as well as are setup for XDG autostart (/ etc/xdg/autostart). These files are setup in the program debs, therefor they are already there and included in the iso/system. Being already there why not have an option to utilize it.
- a startup file function / hook as why replicate one item you would always want started in any window manager you are in to all the various window manager startups.
- command to set screen blank times, configurable through set-screen-blank (can be independant, but as seen in previous releases needs to be in startup otherwise settings are"forgot")
The items were added to desktop-session for a couple of basic reasons:
- as it would be there for the"alternate desktop" function. Therefor would be central to all window managers and could be uses for"session" related items (XDG / common startup items / etc)
- had potential for greater accuracy in knowing when the window manager was started and handling the"basic startup apps" (wallpaper / conky )starting (to avoid"ghost windows", prevent conky from starting below the icon manager (rox/space), preven the wallpaper from setting before the icon manager was running (Blank grey rox pinboard? ) The delay is set high by default for older computers (p2/3) in desktop-session.conf, you could most probably tune it in better for quicker load times (my laptop/desktop with space-fluxbox can be set to"0" for delay)
Drop it maybe... it does not seem to be very popular.dolphin_oracle wrote: dave, what are your plans for the desktop-session system?
1. simplifying the configuration (one set of config files)
2. removing desktop-menu from the sequence?
3. are you adding anything?
4. fixing desktop-defaults (which I assume you are doing since it affects antiX-15 users)
5. Is/will desktop-session be anything more than a wrapper around the chosen WM starting? If so, what?
It was something thought/talked about followed by a work from BitJam (core startup and shutdow / alternate desktops) and I (added startup / session items).
I was adding the items in an attempt to fix issues that were expressed in the forums about applications having issues without"session variables" (lxappearance / bluetooth for me and some others that I cannot recall), ghost windows, startup lapses (grey emtpy pinboard, volumeicon missing from tray, conky behind icon manager, etc), others.
If it should be decided / viewed as beneficial and therefor worthy to be kept...
1. Yes the user configuration (I admit global vs user was an error in thought on my part)
2. I do not think I put it in... I had it to set only on installation via apt and in the root menu. IIRC anti wanted it in there as on live cd there would be no application menu or it was in the wrong language or something of the sort. My thought on a solution was a first run script you could put all items needed on first run in ( /usr/share/desktop-session/first-run-script). Some things made it there some elsewhere... it could be cleaned up and moved to there as far as I know (it is how I have it on my computers). It does make the desktop load faster for installed (or live with persist). Along with this 'solution' was the requested first run dialog option and the changable text file (/usr/share/desktop-session/first-run-text). Meant to be similar to MX 15 first run help window, but it did not go that far.
3. I would like to continue to add:
- mouse setting loading ( like set-screen-blank configures the screen blank time and is renewed via desktop-session next login )
- keyboard setting loading ( again like set-screen-blank configures the screen blank time and is renewed via desktop-session next login )
- try to setup arandr's export setting so that desktop-session can run it (currently possible by exporting, then adding the resulting script to desktop-session/startup)
- possibly a"save desktop" like xfce has, but this is difficult and I know both BitJam and I have tried to make something (BitJam more than I, I think) and have turned out not so reliable or successful
4. I think this should be done, refer to other thread (post44979.html#p44979)
5. Hmm, maybe? I do not really know, but for the moment it would seem to continue to be a wrapper of sorts.
Yes it has been blamed for ALOT. Some of it as far as I know was worth the blame (user / global configuration confusion) others like your case... maybe not so much. I am EXTREMELY BAD for not making documentation outside of the script (or even in the script). I am not gifted in the art of language, as an example this message took between 1.5 hours to write __{{emoticon}}__dolphin_oracle wrote: I'm going to admit that many problems I associated with desktop-session on my eeepc are actually a problem in the parallel nature of the boot chain, with slim starting up before the system is actually ready for it. But desktop-session was easy to point a finger at because it is new. and its shows running in htop so the user is left with the conclusion that its doing something. and since its unique to antiX, there is no information available other than a configuration paragraph in the faq.
-
dolphin_oraclePosts: 2,238
- Joined: 16 Dec 2007
#64
Thanks for the info.
As the team moves toward alphas and betas of antiX-16, hopefully now that we know what its supposed to be doing we will be able to catch bugs easier.
You are actually doing a heck of a lot with really no impact on system resources. and no daemons staying up in ram all the time.
I'm glad to hear that the configuration will be simplified. That will clear up the issues regarding conflicting startup files.
As the team moves toward alphas and betas of antiX-16, hopefully now that we know what its supposed to be doing we will be able to catch bugs easier.
You are actually doing a heck of a lot with really no impact on system resources. and no daemons staying up in ram all the time.
I'm glad to hear that the configuration will be simplified. That will clear up the issues regarding conflicting startup files.
-
SamKPosts: 1,028
- Joined: 21 Aug 2011
#65
Run once will stream or download the video then close. System resources are only used while they are perfoming the task.
Icon places an icon in the taskbar system tray. System resources are used to display this while it is waiting to perform a task.
In this way Streamlight stays in step with the antiX goal of being lean and mean. The user has control and makes the decicion of how their resources are allocated.
There is also a means of automatically starting icon mode at each log-in. It is described in the Streamlight section of the antiX FAQ.
Perhaps a technique such as this might be used with Search Bar.
There appears to be a misunderstanding about the section of my post that you have quoted. That part is referring to a perceived shift in strategy within antiX-15 rather than the value of any of the apps mentioned.skidoo wrote:regarding default autostart items:A concerning aspect is that each of them is active by default.
[...]
According to this post by anticapitalista that is not entirely accurate. post36951.html#p36951 Because SSH is extensively used the antiX configuration seems quite appropriate, particularly as the installation routine asks the installer to choose which services should be active or inactive.skidoo wrote:ssh server is set to autorun by default...
This would have further exacerbated effect underlying the strategic point I was trying to make.skidoo wrote:...but clipboard manager is not.
For a potential alternative way, start Streamlight from the Sound and Video section of the antiX main menu. It presents the following windowskidoo wrote:Search icon in tray is a standout feature. [...]
Compared to"documenting availability of, and how to enable", autostarting them seems reasonable to me.
Run once will stream or download the video then close. System resources are only used while they are perfoming the task.
Icon places an icon in the taskbar system tray. System resources are used to display this while it is waiting to perform a task.
In this way Streamlight stays in step with the antiX goal of being lean and mean. The user has control and makes the decicion of how their resources are allocated.
There is also a means of automatically starting icon mode at each log-in. It is described in the Streamlight section of the antiX FAQ.
Perhaps a technique such as this might be used with Search Bar.
-
dolphin_oraclePosts: 2,238
- Joined: 16 Dec 2007
#66
suggestion for desktop-defaults .desktop files in /usr/share/applications/antix/
add the mimetype information for the proper category to the .desktop files. The links will show up in spacefm open-with that way.
also, if the mimetypes are included in the .desktop files, then it may be possible to set the default apps to desktop-defaults-run apps OOTB for those categories that are covered. then, selecting the preferred application in desktop-defaults-set would actually change the default apps in spacefm (and rox if rox was set up to use desktop-defaults-run -X instead of a given app) from a user point of view if not form an actual system point of view.
add the mimetype information for the proper category to the .desktop files. The links will show up in spacefm open-with that way.
also, if the mimetypes are included in the .desktop files, then it may be possible to set the default apps to desktop-defaults-run apps OOTB for those categories that are covered. then, selecting the preferred application in desktop-defaults-set would actually change the default apps in spacefm (and rox if rox was set up to use desktop-defaults-run -X instead of a given app) from a user point of view if not form an actual system point of view.
-
skidooPosts: 1,445
- Joined: 09 Feb 2012
#67
Sam, thanks for the reminder link: post36951.html#p36951
I guess what I encountered was that"LMX" disabled or one/some of the services I did indeed need during live session
so I wasn't using that cheat (and wound up with ssh enabled"by default" as a result).
I guess what I encountered was that"LMX" disabled or one/some of the services I did indeed need during live session
so I wasn't using that cheat (and wound up with ssh enabled"by default" as a result).
-
skidooPosts: 1,445
- Joined: 09 Feb 2012
#68
The QT+webkit skeletons of the MX Linux and LinuxLite welcome apps are waaaay too complex, IMO.
Hopefully we could find, or create, a python+gtk (tabbed notebook, similar to antixCC?)"welcome" container.
selection of individual tray icons, and autostarted services, and clipboard manager... are perfect candidates for presentation within a"welcome" app.The user has control and makes the decicion of how their resources are allocated.
There is also a means of automatically starting icon mode at each log-in. It is described in the Streamlight section of the antiX FAQ.
Perhaps a technique such as this might be used with Search Bar.
The QT+webkit skeletons of the MX Linux and LinuxLite welcome apps are waaaay too complex, IMO.
Hopefully we could find, or create, a python+gtk (tabbed notebook, similar to antixCC?)"welcome" container.
-
SamKPosts: 1,028
- Joined: 21 Aug 2011
#69
Re Session Management et al
@Dave
Making such fundamental changes when there was little or no community groundswell for them, and therefore little community involvement, combined with a lack of a means of troubleshooting and lack of documentation, is opening the door to criticism.
Putting in place a mechanism that is unique to the distro means the wealth of web based resources cannot be used. In turn this means the antiX community is unable to diagnose and advise on problems. The only source of advice, fixes, and support is directly from the authors/developers. You are the only authoritative source of information. Only you can decide whether that is a situation you, personally, wish to continue. From the point of view of a supportive community it probably falls short of an ideal position.
Doubtless the motivation to introduce session management was done with the best of intentions, however purity of intentions alone is not a guarantee of success. antiX has become a strongly independent distro with it own blend of characteristics. Trying to copy features such as session management from other distros moves antiX away from its independent stance and closer to the herd. In effect it dilutes the characteristics that make antiX, antiX. We should only cherry pick from other distros when it enhances the autonomy of antiX rather than diminishing it.
@Dave
I can empathise strongly with you on this. I find writing anything extremely difficult. It takes a disproportionate amount of time and effort to write even the smallest piece. By way of example the 2 FAQ sections for the 1-to-1 suite took weeks to complete rather than a few hours or even a few days. I see the documentation as an integral part of the development process. I strive to prevent the difficulty (and personal dislike of doing it) from overtaking the belief that it is needed and beneficial.Dave wrote: I am EXTREMELY BAD for not making documentation outside of the script (or even in the script). I am not gifted in the art of language, as an example this message took between 1.5 hours to write __{{emoticon}}__
This was probably a predictable outcome.Dave wrote:...it has been blamed for ALOT.
Making such fundamental changes when there was little or no community groundswell for them, and therefore little community involvement, combined with a lack of a means of troubleshooting and lack of documentation, is opening the door to criticism.
Putting in place a mechanism that is unique to the distro means the wealth of web based resources cannot be used. In turn this means the antiX community is unable to diagnose and advise on problems. The only source of advice, fixes, and support is directly from the authors/developers. You are the only authoritative source of information. Only you can decide whether that is a situation you, personally, wish to continue. From the point of view of a supportive community it probably falls short of an ideal position.
Doubtless the motivation to introduce session management was done with the best of intentions, however purity of intentions alone is not a guarantee of success. antiX has become a strongly independent distro with it own blend of characteristics. Trying to copy features such as session management from other distros moves antiX away from its independent stance and closer to the herd. In effect it dilutes the characteristics that make antiX, antiX. We should only cherry pick from other distros when it enhances the autonomy of antiX rather than diminishing it.
dolphin_oracle wrote:dave, what are your plans for the desktop-session system?
If you do decide to drop it, the decision will not be an easy one to reach. It will take great strength of character.Dave wrote:Drop it maybe... it does not seem to be very popular.
-
skidooPosts: 1,445
- Joined: 09 Feb 2012
#70
posting this more as a"kick the tires" idea than a solid suggestion:
Consider adding a"welcome" tab to the antix ControlCentre.
Show that notebook tab by default or, first run (if no state files are present) launch controlCentre with
a commandline argument which specifies"launch, and focus the welcome tab".
A welcome really doesn't need to include direct (redundant) command launchers, just links to open
local antix webpage helpdocs into a browser. Getting started, setting session autostart/tray items,
guide to selecting autostarted services, persistence setup docs, howto setup left-handed Estonian kb+mouse...
Consider adding a"welcome" tab to the antix ControlCentre.
Show that notebook tab by default or, first run (if no state files are present) launch controlCentre with
a commandline argument which specifies"launch, and focus the welcome tab".
A welcome really doesn't need to include direct (redundant) command launchers, just links to open
local antix webpage helpdocs into a browser. Getting started, setting session autostart/tray items,
guide to selecting autostarted services, persistence setup docs, howto setup left-handed Estonian kb+mouse...
-
Posts: 1,445
skidoo - Joined: 09 Feb 2012
#71
suggestion:
Toward avoiding launch of root-permissioned browser, assign aliases within /root/.bashrc
Toward avoiding launch of root-permissioned browser, assign aliases within /root/.bashrc
Code: Select all
alias iceweasel='roxterm --title=__PREVENTED_ROOTUSER_BROWSER_LAUNCH__'
alias dillo='roxterm --title=__PREVENTED_ROOTUSER_BROWSER_LAUNCH__'
# proactive, in case user later installs an alternative browser
alias firefox='roxterm --title=__PREVENTED_ROOTUSER_BROWSER_LAUNCH__'
alias torbrowser='roxterm --title=__PREVENTED_ROOTUSER_BROWSER_LAUNCH__'
alias chromium='roxterm --title=__PREVENTED_ROOTUSER_BROWSER_LAUNCH__'
alias chrome='roxterm --title=__PREVENTED_ROOTUSER_BROWSER_LAUNCH__'
alias qupzilla='roxterm --title=__PREVENTED_ROOTUSER_BROWSER_LAUNCH__'
alias vivaldi='roxterm --title=__PREVENTED_ROOTUSER_BROWSER_LAUNCH__'
alias opera='roxterm --title=__PREVENTED_ROOTUSER_BROWSER_LAUNCH__'- Posts: 307 eugen-b
- Joined: 23 Aug 2015
#72
@skidoo, you forgot palemoon __{{emoticon}}__ it got new 26.0.0 version with many changes yesterday, BTW.
midori is also somewhat popular.
midori is also somewhat popular.
-
EperbabPosts: 146
- Joined: 10 Dec 2012
#73
I have found this idea to reduce memory consumption:
The package called"libicu" contains all localisations. It is around 22 MB, and heavily used. It can be recompiled with the"--with-data-packaging=archive" parameter. It will move localisations from"/usr/lib/i386-linux-gnu/libicudata.so" to"/usr/share/icu/*/icudt*.dat". It is possible to choose the localisations actually needed, see here:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://apps.icu-project.org/datacustom/"
linktext was:"http://apps.icu-project.org/datacustom/"
====================================
With 2 localisation kept, the end result is around 2 MB.
If we could move localisation selection & *.dat generation to the installer menu, then it would reduce memory consumption by ~ 20 MB.
It would move AntiX closer to the"lightest distro" title.
The package called"libicu" contains all localisations. It is around 22 MB, and heavily used. It can be recompiled with the"--with-data-packaging=archive" parameter. It will move localisations from"/usr/lib/i386-linux-gnu/libicudata.so" to"/usr/share/icu/*/icudt*.dat". It is possible to choose the localisations actually needed, see here:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://apps.icu-project.org/datacustom/"
linktext was:"http://apps.icu-project.org/datacustom/"
====================================
With 2 localisation kept, the end result is around 2 MB.
If we could move localisation selection & *.dat generation to the installer menu, then it would reduce memory consumption by ~ 20 MB.
It would move AntiX closer to the"lightest distro" title.
-
anticapitalista
Posts: 5,955
- Site Admin
- Joined: 11 Sep 2007
#74
Seems like a good find. However, we also aim to have as much localisation on the live iso as we can for those that wish to run antiX in live mode either as a frugal install, or persistence on a usb stick with user language. I'm not sure if only having a default English iso (or including a few more like French, German) is the best solution. I'll look into it more - thanks.Eperbab wrote:I have found this idea to reduce memory consumption:
The package called"libicu" contains all localisations. It is around 22 MB, and heavily used. It can be recompiled with the"--with-data-packaging=archive" parameter. It will move localisations from"/usr/lib/i386-linux-gnu/libicudata.so" to"/usr/share/icu/*/icudt*.dat". It is possible to choose the localisations actually needed, see here:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://apps.icu-project.org/datacustom/"
linktext was:"http://apps.icu-project.org/datacustom/"
====================================
With 2 localisation kept, the end result is around 2 MB.
If we could move localisation selection & *.dat generation to the installer menu, then it would reduce memory consumption by ~ 20 MB.
It would move AntiX closer to the"lightest distro" title.
-
skidooPosts: 1,445
- Joined: 09 Feb 2012
#75
Hmm, did I forget PaleMoon... or did I choose to ignore it?
Ironically, When I typed the post about aliasing, one of my browser tabs was:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://forum.palemoon.org/viewtopic.php?f=5&t=10817"
linktext was:"https://forum.palemoon.org/viewtopic.php?f=5&t=10817"
====================================
The"xss filter" feature they're crowing about in the new release...
yeah, 2 yrs late to the table, playing catch-up with firefox (or firefox addon) feature parity.
As is evident across my past posts, I've really had a chip (or three) on my shoulder in regard to PaleMoon.
I haven't"let loose both barrels" when posting, haven't taken the time to fully explain the details.
More recently (than any of my posts here regarding PaleMoon), I do recognize the increasing"viability" of PM
as firefox drifts further"off the f'ing rails" with each release, but still... naw.
Most of this linked PaleMoon"rumor control" post is true... but some of it is"spin".
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://forum.palemoon.org/viewtopic.php?t=7818"
linktext was:"http://forum.palemoon.org/viewtopic.php?t=7818"
====================================
Changing the app GUID string (wrecking addon compatibility) was a bad move, or at least poor timing.
Whatever the rationalization, that decision was NOT in users' (nor addon devs) best interest.
Does PaleMoon dev really care more about protecting your privacy than the firefox devs?
More than the TorBrowser devs? (Note: tor focuses on"anonymity"; I focus on _privacy_ )
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://forum.palemoon.org/viewtopic.php?f=26&t=8894"
linktext was:"https://forum.palemoon.org/viewtopic.php?f=26&t=8894"
====================================
In the above linked thread, I am not a participant.
I am pissed to see the (non)resolution though, and the PaleMoon dev's attitude...
...considering that I am zinc @trac.torproject.org (the original reporter)
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://trac.torproject.org/projects/tor/ticket/13398"
linktext was:"https://trac.torproject.org/projects/tor/ticket/13398"
====================================
Although I can cite other examples, I chose this one because to me it seems clear-cut, black-and-white.
It's a"privacy-invasive, by design" behavior. The user is powerless to opt out (and *cough* trust his pref will be respected?)
-=-
We're told over and over, ad nauseum"it's open source, anyone can review the code to check for backdoors, and..."
and, to what end?!?
Specific to the PM handling of the reported question/issue:
I can't place faith nor trust in the PM dev -- he's too lazy to spend 2 minutes resolving the issue
by (for instance) simply inserting"return NS_ERROR_NOT_IMPLEMENTED" into the offensive getUserInfo functions.
Per the dismissive PM dev's reasoning,"is a non-issue, cuz we hab remove telemetry"... yet this same dev has posted
and/or drafted changelogs bragging (?)"firefox Health Report: Kill it with FIre!!!"
(BTW: removing FHR, and crowing about it, amounts to"picking low-hanging fruit")
I'm currently wading neck-deep though the firefox codebase(s) (v38.5esr, thru v46.x)
and have compared iceweasel patches, torbrowser patches, and palemoon code.
From what I've seen, ICEWEASEL is the current best choice (lesser evil) IMO.
Ironically, When I typed the post about aliasing, one of my browser tabs was:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://forum.palemoon.org/viewtopic.php?f=5&t=10817"
linktext was:"https://forum.palemoon.org/viewtopic.php?f=5&t=10817"
====================================
The"xss filter" feature they're crowing about in the new release...
yeah, 2 yrs late to the table, playing catch-up with firefox (or firefox addon) feature parity.
As is evident across my past posts, I've really had a chip (or three) on my shoulder in regard to PaleMoon.
I haven't"let loose both barrels" when posting, haven't taken the time to fully explain the details.
More recently (than any of my posts here regarding PaleMoon), I do recognize the increasing"viability" of PM
as firefox drifts further"off the f'ing rails" with each release, but still... naw.
Most of this linked PaleMoon"rumor control" post is true... but some of it is"spin".
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://forum.palemoon.org/viewtopic.php?t=7818"
linktext was:"http://forum.palemoon.org/viewtopic.php?t=7818"
====================================
Changing the app GUID string (wrecking addon compatibility) was a bad move, or at least poor timing.
Whatever the rationalization, that decision was NOT in users' (nor addon devs) best interest.
Does PaleMoon dev really care more about protecting your privacy than the firefox devs?
More than the TorBrowser devs? (Note: tor focuses on"anonymity"; I focus on _privacy_ )
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://forum.palemoon.org/viewtopic.php?f=26&t=8894"
linktext was:"https://forum.palemoon.org/viewtopic.php?f=26&t=8894"
====================================
In the above linked thread, I am not a participant.
I am pissed to see the (non)resolution though, and the PaleMoon dev's attitude...
...considering that I am zinc @trac.torproject.org (the original reporter)
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://trac.torproject.org/projects/tor/ticket/13398"
linktext was:"https://trac.torproject.org/projects/tor/ticket/13398"
====================================
Although I can cite other examples, I chose this one because to me it seems clear-cut, black-and-white.
It's a"privacy-invasive, by design" behavior. The user is powerless to opt out (and *cough* trust his pref will be respected?)
-=-
We're told over and over, ad nauseum"it's open source, anyone can review the code to check for backdoors, and..."
and, to what end?!?
Specific to the PM handling of the reported question/issue:
I can't place faith nor trust in the PM dev -- he's too lazy to spend 2 minutes resolving the issue
by (for instance) simply inserting"return NS_ERROR_NOT_IMPLEMENTED" into the offensive getUserInfo functions.
Per the dismissive PM dev's reasoning,"is a non-issue, cuz we hab remove telemetry"... yet this same dev has posted
and/or drafted changelogs bragging (?)"firefox Health Report: Kill it with FIre!!!"
(BTW: removing FHR, and crowing about it, amounts to"picking low-hanging fruit")
I'm currently wading neck-deep though the firefox codebase(s) (v38.5esr, thru v46.x)
and have compared iceweasel patches, torbrowser patches, and palemoon code.
From what I've seen, ICEWEASEL is the current best choice (lesser evil) IMO.