Leaderboard

IIRR, @glnz actually *IS* a lawyer, so I'm hereby asking him to ping in and kindly provide us some advice, which sure'll be much appreciated!

I'm not an expert on Open Source licensing either, but apparently someone here is going to have to become one... This whole business is ridiculous. I would prefer to see the great "dispute" settled as well, because it IS in everyone's best interests to NOT be fighting each other, BUT - NOT by simply giving in to the constant threats/intimidation coming down from "on high." I don't speak for anyone but myself, but if it were up to me I would not lift a finger to conform to any "demand" until some degree of mutual respect is established. The first step of which must include "them" putting a stop to the constant disparaging of the "XP (and Vista ) community" and "our" choices - as if anyone here needs "their" approval to use any given OS, or gives one iota what "they" think about our choice of that OS. That being said, I figured the "branding" problem would be simple enough.. just revert that particular change. While "they" will surely be very angry about it, in the end, (AS FAR AS I KNOW) they cannot force the change "retroactive" on already released code/versions/files. Even if they wanted to take the time and go through all of those old versions, and push out another update for each with the change, it would not erase what has already been made public, and is already covered under the "previous" existing license/redistribution conditions. These "private" repository issues are another aspect which we must figure out with regard to the licensing conditions. I see this "behavior" as simply an attempt to create more hassle for anyone who wishes to build the code for themselves.. which most certainly violates the "spirit" of Open Source, and may violate the actual licensing, depending on which licenses are applicable to different parts of the code. The MPL 2.0 (which to my knowledge governs the Firefox code that PM is developed from) contains some interesting specific statements that would seem to be relevant here: "All distribution of Covered Software in Source Code Form, including any Modifications that You create or to which You contribute, must be under the terms of this License." "You may not attempt to alter or restrict the recipients’ rights in the Source Code Form." "...Covered Software must also be made available in Source Code Form, as described in Section 3.1, and You must inform recipients of the Executable Form how they can obtain a copy of such Source Code Form by reasonable means in a timely manner..." "You may distribute such Executable Form under the terms of this License, or sublicense it under different terms, provided that the license for the Executable Form does not attempt to limit or alter the recipients’ rights in the Source Code Form under this License." ... so, I see it as a question of whether or not these statements are to be "understood" at face value. If so, then I'm not so certain that "private" repositories and "hoops to jump through" to obtain sources are not in direct violation of this.

Well, technically we aren't using their branding anymore since they just abandoned what we're using now. We now have a different product to theirs with different branding, which is most of what they wanted. Though there may still be some sort of trademark attached to their old branding. And Serpent isn't resolved though I don't think they are too pleased about us brand leeches either way (either we piggyback on their current unofficial branding or simply seize/gift ourselves their old branding). And New Moon could still evoke memories of Pale Moon (for an unfortunate few anyway).

Let me begin by thanking you for continuing to deliver updated builds of your browsers, despite the recent major hardware hardships... (pun intended! ) Starting with last weekend's New Moon 28 package (linked-to above) and including this weekend's latest NM28 offering, I've noticed that 3 compiled files, all previously associated with Serpent 52.9.0 builds, have somehow slipped into New Moon's main app directory; these files are: Accessible.tlb AccessibleMarshal.dll IA2Marshal.dll I browsed quickly your custom UXP branch and did not find any clues there as to why these 3 files now appear inside NM28's main appdir ; if it's any info, these 3 files also do not appear inside upstream official compilations of Pale Moon 28.13.0/29.0.0a6; but since our fork has deviated somewhat from upstream, that fact may or may not be relevant... Mentioned files, as pretty much expected, continue to reside inside Serpent 52.9.0's main appdir (as well as in upstream official Basilisk 52.9.2020.09.11 ) Now, as a test, I went along and deleted those 3 "errant" files and latest New Moon 28.10.2a1 32-bit (buildID=20200918232718) launches and runs fine here (Vista SP2 32-bit, build 6.0..6003) without them... It looks as if those files are generated via a first stage Serpent/UXP compilation and are then added, by mistake, with other compiled files that are common/shared with the New Moon 28/UXP compile/build (possibly to expedite compilation of both UXP browsers...); if that's by design (and may I note that this wasn't the case with the previous [now lost] building environment), perhaps it would be best to remove those 3 unneeded (for NM28) files post compilation and prior to packaging/uploading... https://github.com/MoonchildProductions/UXP/issues/1653 Clean up Windows widget code https://github.com/MoonchildProductions/UXP/commit/6f5cd8a [widget] Clean up Windows widget code some. Can you please elaborate a bit why upstream UXP#1653 was not merged? Would it have broken WinXP compatibility if it had? Being on Vista here (NT 6.0), could this have been handled slightly differently if it provides performance improvements on Vista+? (e.g. ifdef'd to load the code under Vista+ but not under XP?) Apologies if I'm asking something that can't be done... I'm really sorry to have to bring this up, but don't you expect "upstream" to hear about that? You are, at the end of the day, still building "unofficial" Pale Moon builds and upstream have modified that branding (which is their prerogative, it appears...). I won't pretend I understand fully the Open Source licensing schemes, but I smell (additional) trouble coming from upstream, this time from Moonchild himself With all said and done (and undone) in the past, I'd hate to witness any further escalation between "us" and "them", especially if it results in more restrictive action(s)/sanctions from upstream... What do others think on this? Finally, I don't use any of these forks myself, but out of pure (healthy) curiosity, what source do you actually use now to produce updated builds of? AFAIAA, upstream have moved to a private repository, so are you now just updating the platform (UXP) submodule/component, which is still public? Thanks for all your hard work and efforts , thanks in advance for any answers received... Best greetings

Perfect . A mechanical and electrical engineer might tell you that you are either extremely lucky (and the two surfaces match perfectly) or you are compensating the lost efficiency of the thermal exchange with (unneeded) increased ventilation (i.e. fan spins more and faster than it could be enough). I will only invoke Dhukat : https://jdebp.eu/FGA/dukhat-on-foolishness.html jaclaz

I'll remind people here that I'm not actually an authority on Google Chrome and Chromium derived browsers, having been from the very start a Mozilla Firefox user, first (2005-2008) on a WinXP desktop and then (2008-2018?) on this Vista laptop... This is to clarify that I haven't followed closely Chromium's development during that era... I've learned quite a few things from XP users of Chrome 49, and it's true that specific [old] version (officially the EoS one for XP/Vista) does rely on OS resources/libraries for secure connections (which involve both available TLS protocols and available cypher suites). Contrary to what Google (the No.1 enemy of the Vista OS, by far ) believed, WinVista != WinXP, so having a fully updated Vista SP2 OS with TLS 1.2 support will grant you more accessible websites using Chrome 49 on Vista, thanks to Vista supporting more cypher suites by default and, on top of that, having SNI support that WinXP lacks... But all this is probably a moot point already, because Chrome 49's rendering engine is antiquated by now... To conclude, yes, Chromium 49 can only go up-to TLS v1.2 on an updated Vista system (with KBs targeting WS2008 originally ) At some point further down its development, Chromium disengaged to a degree from OS libs where TLS support is concerned, so that Chromium 57/58, upon which Yandex Browser (YB) 17.4/17.6 builds, comes with bundled/native support for the TLS protocol. I haven't used YB 17.6 (portable) here for many months, having long ago switched, first to 360EE v11 (Chromium 69 based), then to 360EE v12 (Chromium 78 based) and currently testing (beta channel of) 360EE v13 (Chromium 86 based). YB 17.x has other significant shortcomings by now, affecting Google Web Store (GWS) support , but that is part of a future post about YB 17.x ... By default, YB 17.6 supports TLS 1.0+1.1+1.2, provided by its own (Chromium) libs (i.e. non-dependent on OS TLS support, kinda like Firefox); but there is latent TLS 1.3 support, too, which can be enabled via a browser flag; The problem is that YB 17.6 was released at a time when TLS 1.3 hadn't been finalised yet, so it only supports a TLS 1.3 draft preceding the final one (i.e. RFC8446) Testing on dedicated TLS testing sites you get mixed results, depending on whether the test site detects pre-final TLS 1.3 drafts or not; SSL Labs client test picks up pre-final TLS 1.3: ... but Browserleaks ... and pinterjann DO NOT! As a closing note, if you want to disable lower, deemed currently insecure, versions of TLS, you can launch YB via a shortcut containing the following flag: --ssl-version-min=tls1.2 or --ssl-version-min=tls1.1 if you want to disable just TLS 1.0 ...

will go if I remember to do this.

The last release channel version of WSUS Offline with Vista support was v10.9.2, released on 2017-03-19; the last release channel version of WSUS Offline with WS2008 support was v11.8.3, released on 2019-11-14. Vista users should probably use the ESR channel of WSUS Offline; the last/most recent version advertised on their download page with any Vista support is v9.2.5, released on 2019-06-04: https://download.wsusoffline.net/ => Archive However, there's still a more recent v9.2.6, not being publicly advertised, released on 2019-11-08: https://download.wsusoffline.net/wsusoffline926.zip

Microsoft shut down Windows Update for XP, Vista and older, but it should still work for Windows 7 and newer provided that SHA-2 support has been installed: https://support.microsoft.com/en-us/help/4569557/windows-update-sha-1-based-endpoints-discontinued

that's the accessibility libraries, official builds and my old builds used to have --disable-accessibility specified. I lost the build config and then it turns on that on compilation. yes it breaks XP support, for example, it loads DWM in link-time, which XP doesn't even have this DLL. same condition as hyperbola(i.e. no updates), as they aren't update their part, but UXP core still bring new function to them.

OK so, in addition to MPC-HC and Pot Player via 3DYD YTS I am now also able to stream YouTube videos without 3DYD in older versions of MPV, VLC, Osmo4 (GPAC), QMPlay2 and current/latest Mplayer Sherpya build from right click in both Opera 12 and Gecko Browsers. I've also made a quite fancy and useful GUI for Youtube-dl as it turned out I couldn't find any working properly on 9x (not any good one anyway). Coming soon, probably next week, as part of the Youtube-dl 4 98SE-ME Megapack (500MB). Screenies of the GUI for now: