A recent update broke the file history service for me, which I only discovered when I went to restore a previous version of a file. If you use it too, you should probably check it's actually working.
When it works it's amazing. Files are saved as is with date time stamp appended, so all do is to undo that. Great if you trashed something a while back and always quicker than getting it back via github. Haven't found anything using a similar approach - just copy the change to the mirror. if the file is moved, just make a copy of the changed file, if it is deleted, who cares, just ignore from then on. simple. Everyone else is being way too clever, compression and exact deltas history, etc
One recent issue required cloning the user account to get file history working. Just would not work with that account while any new account worked fine.
Current status is broken - the last two security updates report file history as broken. Git hub handles code ok, but for all the other stuff on windows file history was the way to go. Now cumbersome incremental backups.
> content can load without the blocker being ready to filter
This isn't an MV3 issue, it's a Chromium design decision that extensions cannot block browser initialization. It was also true with MV2. In fact, MV3 has improved the situation because DNR rules are enforced immediately.
You could certainly argue that Chrome should allow extensions to block browser initialization, or that it should be user configurable - but it seems like an entirely defensible Chrome decision. Regardless, it's nothing to do with MV3.
> the filter rules aren't as flexible.
That's true, but they are still very flexible, and DNR makes some very nice features possible in uBO lite that were not possible in uBO.
For example, did you know that you can change your User-Agent with uBO lite? Go to the Custom DNR rules tab, and enter something like this to pretend to be Lynx on whatever.com:
Any MV3 issue could probably be summed up as "MV3 isn't so bad, just the implementation in Chrome" where Chrome defines MV3 (as it's not a W3C standard) and ships it as such.
That said,
> Chromium design decision that extensions cannot block browser initialization
It's not "browser initialization" that was blocked, it was blocking network requests for pages until they were processed by all components in the chain. Notably, this could never apply applied to the browser or its internal pages itself.
Firefox is a great example about all of the above points: MV3 still supports blockingWebRequest there, so it gets the best of both worlds.
> did you know that you can change your User-Agent with uBO lite?
With MV2 you'd use blocking webRequest and chrome.webRequest.onBeforeSendHenders. I'm not sure uBO ever bothered with this before uBO Lite, but it's a bit of a double standard to say "MV2 didn't offer blocking requests, that was a different API which happ
> and then the request had to wait until it was given to and processed by the blocker.
Despite the name, the requests were not blocked until the extension had initialized. The browser could make network requests before that happened with MV2. With MV3, static rulesets and persistent DNR rules are enforced immediately.
> With MV2 you'd use blocking webRequest and chrome.webRequest.onBeforeSendHenders
Of course an extensions could do this, I said uBO lite. DNR made exposing this powerful functionality fast and easy. My point is that MV3 uBO lite has useful features that MV2 uBO does not.
> Despite the name, the requests were not blocked until the extension had initialized. The browser could make network requests before that happened with MV2. With MV3, static rulesets and persistent DNR rules are enforced immediately.
There were several workarounds like suspendTabsUntilReady which helped greatly in this half of the problem. Then it would solidly stay permanently registered too. I'm pretty sure none of these work in Chrome anymore though, it was obvious they never intended these sorts of things to work that way.
Nevertheless, MV3's ability to offer limited filtering on startup does not seem like such a blessing when the other option was to just guarantee full filtering on startup as seen in this change https://bugzilla.mozilla.org/show_bug.cgi?id=1447551
> Of course an extensions could do this, I said uBO lite. DNR made exposing this powerful functionality fast and easy. My point is that MV3 uBO lite has useful features that MV2 uBO does not.
What you said is so, it just might highlight more than what you'd like it to at the same time. That it was missing before had nothing to do with the difficulty or need for MV3. uMatrix had it for a while and Gorhill regretted it because it didn't change things like the user agent JS would report and such, hence he wouldn't port it over. The above filter has the same problems. Great if you just want a normal quality user agent switcher, that it's normal quality is why it was never in the old extension though.
> Nevertheless, MV3's ability to offer limited filtering on startup does not seem like such a blessing when the other option was to just support full filtering on startup
Sure, but as I said, it's a design decision, and nothing to do with MV3. I'm not trying to litigate it one way or the other.
I do think DNR is a good solution, and that request callbacks were a bad idea. That's my opinion - and the counterargument is obvious -- you can't do literally everything you could do in a callback declaratively. That doesn't sway me, I still think it's better!
> Great if you just want a normal quality user agent switcher
It was just a trivial example of using a powerful new feature that uBO doesn't have, not a full featured extension! The fact that it's possible at all is the point, it's cool.
You can definitely do anything that DNR can do with webRequest, nobody can dispute that. The point is that there are things you can do with uBO lite that you can't do with uBO (and vice versa!). It's not a straight downgrade, there are powerful new features.
Again, we really need to separate "MV3 - the theoretical idea" and "MV3 - the actual implementation which ships with Chrome". It's two confusingly different worlds.
Nobody should be swaying you to prefer DNR over webRequest (or vice versa) when other browsers show both can be available options for the extensions you use as makes sense for what they try to do/what type you'd like to install. Continuing to support MV2 power levels of functionality does not mean uBO Lite type extensions would need to stop working the way they do, it means uBO type extensions would continue to work the way they do. I.e. the biggest failure of MV3 is not in lacking anything new whatsoever, it's in forcing the removal of a lot of API options which were useful in the name of ulterior motives.
> You can definitely do anything that DNR can do with webRequest, nobody can dispute that. The point is that there are things you can do with uBO lite that you can't do with uBO (and vice versa!). It's not a straight downgrade, there are powerful new features.
It's like you sold your house for a mobile home but tell the neighbor it's not a straight downgrade because it's red. Great, but why are we praising that instead of painting the house red?
Funnily enough, this morning I ran across another feature I didn't realize was missing in MV3 https://github.com/uBlockOrigin/uBOL-home/discussions/369. Perhaps keeping the functionality to know what was actually blocked to the extension was too powerful.
> the biggest failure of MV3 is not in lacking anything new whatsoever, it's in forcing the removal of a lot of API options which were useful in the name of ulterior motives.
What was the ulterior motive? If it was to break ad blocking, it seems like they did a really terrible job, as MV3 ad blockers work great. That's not me saying that, here is a paper from researchers at Goethe University Frankfurt who tested it:
> Moreover, cross-browser experiments yield comparable outcomes, and visual inspection confirms that MV3 ad blockers work effectively without significant ad flickering or loss of functionality
> Funnily enough, this morning I ran across another feature I didn't realize was missing in MV3
I think you could accomplish this by redirecting instead of blocking, then increment a counter in a webRequest callback. There would obviously be a performance cost, as blocking is so cheap and callbacks are expensive...
Regardless, I think it's jarring hearing you call custom DNR rules "painting the house red", a legitimately powerful feature... and then point to a missing counter in the UI as evidence of lacking features!
I think the new features in MV3 are great, and UBO lite is great. The initial versions of UBOl worked, but definitely lost some power user features. Those are basically all back, it now has full scriptlet support, custom dynamic filters work, element zapper is back and you can now have custom dnr rules. That's a very powerful feature that doesn't exist in UBO.
The big loss for me with the mv2 deprecation was uMatrix, so I made my own replacement. It's a prototype, but you can try it if you like: https://github.com/taviso/matrix3
I think the real question is how have Edge and Mozilla shipped WebExtension support on Android, but Google hasn't. If other competent vendors can ship it then there can't be a technical reason, it must be a policy decision. I'm more open to hearing conspiracy theories about that than MV3 :)
I have one of these, there is an open source project called gshock_api that supports it. I think that makes it a much more interesting device. I don't use the app, I tag alarms in remind, and sync them from cron - works great.
This is great, as is the CasioGShockSmartSync Android app. I wish there was an iOS app, as the official app is horrible, only works after signing up for an account, and only works if given every tracking permission possible to vacuum the maximum amount of data to the cloud.
That's nothing to do with MV3 though, that was also true with MV2. The situation actually seems improved in MV3, because static (and dynamic, IIRC) DNR rules are initialized and enforced immediately, right?
I don't have any nostalgia it, I just appreciate how thoughtfully it was designed for data-input efficiency. I actually ported the official UNIX version of 1-2-3 to Linux a few years ago, I still use it regularly. It uses some tricks to get the original UNIX binaries working on Linux: https://github.com/taviso/123elf
I had been thinking about how to add UTF-8 support, it only supports LMBCS (Lotus Multi-Byte Character Set) by default. It's actually worse than that, it stores everything internally as LMBCS but in a lot of cases can only display ASCII, so it transliterates a lot of characters (e.g. é -> e).
It's also possible to run the real DOS version in dosemu - in terminal mode it's basically indistinguishable from an ncurses application, although dosemu is just cleverly sampling the framebuffer and translating it on-the-fly.
I love your pages, they are really great, especially the one about reverse engineering the display driver to discover that 1-2-3 actually supports better display resolutions.
I've been running the DOS version in DosBox-X for Mac at the moment to ground l123 in the reality of what using 1-2-3 was like. I'm using Release 3.4a, which was the last version that didn't go full GUI (R4 for DOS was kind of a Windows-light version). I'm trying to balance fidelity to the original with something that might be useful to actually do some productive work in, especially when one might not need or want the full GUI/overhead of Excel or (shudder) Google Sheets.
What specifically has gone poorly? Is a dozen bug reports high or low compared to previous versions of the software where humans are writing the code?
I don't use ledger-cli myself but I do use the similar software hledger. I don't pay very close attention to hledger's development process, but I haven't noticed any bugs that affect me in years of using it.
A regression here and there would be normal before, major features breaking in this stable 25 year old software is simply unheard of.
This is not exciting cutting-edge software, it's a boring financial app. My instinct is people want stability and confidence that the output won't change and that their records will still parse.
I think apps like this are the real risk. Who is going to get in trouble because vim* has a bug from AI generated code? Errors in your accounting software can get you into audit/compliance trouble.
I saw that tweet and thought it looked crazy. To me, it sounds like a death threat. Especially given that it's posted on X.com, after a really heated argument, with no clarification afterwards.
If you didn't actually post that tweet, that's great! I'm happy to be corrected
If you hear a rumor that sounds too crazy to be true on social media, maybe don't repeat it as fact. Imagine how you would feel reading something like that.
This is XMMS, a X11 Clone of winamp. We all had it on our desktop these days. And hell yeah, our Linux desktop could look anything we wanted. What a time!
reply