Did an AB test a while back and mere presence of the PayPal option boosts sales through all other options plus generates extra sales through PayPal itself. Not something that I was expecting at all, but the confidence level was over 99%.
Electron (accidentally) broke Windows 7 support last month, and as a result a number of applications broke for Windows 7 if they used that Electron version (e.g. VSCode). Lots of people complained. It was a fairly minor thing and was quickly fixed by the Electron people.
My favourite comment in one of the threads about it:
"Related "MS ended support for Win7" - sorry, how it corresponds to development?! Does your operating system gone away from SSD? Or Windows become rusty? Not. SYSTEM WORKS AS BEFORE, so please don't write stupid reasons "MS doesn't support" - nobody care of it, system works as usual and nothing prevents you from using Win7 (as I do now)."
I kind of like the no-nonsense honesty of it; made me smile :-) I don't think it's necessarily smart to keep running on Windows 7 given the support status, but they're not entirely wrong either: Windows 7 is a fine system. It works. Why "upgrade"?
> "Related "MS ended support for Win7" - sorry, how it corresponds to development?! Does your operating system gone away from SSD? Or Windows become rusty? Not. SYSTEM WORKS AS BEFORE, so please don't write stupid reasons "MS doesn't support" - nobody care of it, system works as usual and nothing prevents you from using Win7 (as I do now)."
This is just nonsense. If the user feels so strongly, why don't they maintain the relevant software themselves and find out just how easy (not) it is to maintain support for an EOL operating system? Or why don't they just stick to outdated versions of all their software, like they chose to do with their operating system? Harassing open source developers who work for free is not a sane response.
No one was being harassed. They opened an issue because they were facing a problem, which is what issues are for. The first response was "they need to not offer the update on Win 7. We don't need our environments seamlessly fucked." from some random drive-by commenter. They posted that in reply after it actually got fixed by one of the vscodium maintainers.
You just need to be really really careful about downloading anything (through user action or by the system) to it because there will be a long list of exploits to choose from for anyone wanting a free bitcoin farm. Microsoft might even be paying the 'security researchers' to come up with more.
Forking over a couple hundred to uncle Bill for protection every five years or so is not entirely pointless.
You just need to be really really careful about downloading anything
...as you always should be anyway.
Forking over a couple hundred to uncle Bill for protection every five years or so is not entirely pointless.
...and being forced into their increasingly user-hostile manipulations? If anything, that saying about "known unknowns" and "unknown unknowns" comes to mind.
You're right of course, but I do think the quote accurately represents the feelings a lot of people had, and continue to have, even when they know they should upgrade (and most likely, already have upgraded) due to lack of support.
FWIW, I'd think people buying and using system utilities are more often than not users that run old machines for business reasons. More the "XP machine in the basement to control the boiler" situation rather than "I don't want the free update to Windows 10" situation.
Another thing to keep in mind is that Windows 8.1 is still supported by Microsoft for another three months. Windows 8.1 is not outdated yet, not even according to Microsoft. Chrome's support will end a month after Microsoft's support ends, I'd think because very few people actually use 8.1 compared to the rest of the world.
In case your customers ask, Windows 7/8.1 users may be able to use Firefox (ESR, if necessary) if they want a maintained browser. The current Firefox ESR should be supported until at least August of next year and if Mozilla includes 7/8.1 support in version 115, then support should last until at least the end of next year.
Support is a lot more of a nebulous concept than it used to be. I recall AMD stopped releasing new drivers for Windows 8 at least a couple years ago, even though it is still supported by Microsoft. At the same time they were still releasing Windows 7 drivers even though MS stopped support in 2020.
Thanks! I'll take a look at it again. I remember at one point you were considering using something like git as the format for diffs but weren't sure, did you make any progress on that?
The NAT traversal logic here is really basic and won't hold up well in practice.
A good chunk of NAT devices will pick external port based on [src ip/port, dst ip/port] combo, not just [src ip/port], so "WAN IP/port" you get from STUN will get you nothing useful. Not by itself.
STUNs should be used for discovering the pattern in NAT port overloading logic and then using it to predict which port your peer will use towards you if you were to try and connect now.
That is, you need to know the overloading pattern and then also time stuff correctly.
For that reason you will need a rendezvous server and it's also the best to let the server drive the whole process (as opposed to what STUN-based setups do, which is to let clients do it).
PS. In my past life I made a P2P VPN called Hamachi, which used all this stuff very extensively.
Anyone know if there are any open-source libraries which wrap this all into a usable `get_{tcp,udp}_connection(peer_id)` API, preferably with fallback to a relay server? I feel like there really should be, but nearly all the tools I’ve seen with this functionality are closed source, and the few open-source things all do their own custom logic rather than a shared library :/
Hamachi letted me play Command and Conquer online with my friends! We used Hamachi all the time to be able to play games online through LAN. Thank you so much for improving my childhoods quality of life :)
It's not a terribly complicated subject, but you do need a fair understanding of IP and UDP. TCP too, because it is possible to establish direct TCP connection through two NATs using the symmetrical open clause of the TCP handshake. Looks like magic when you see it work for the first time.
Stevens' book is a must read, yes, but it has nothing even on NAT (iirc), leave alone on working around it. Look at how NAT works, what types of it exist, etc. Then look at "hole punching". For bonus points skim through p2p-hackers mailing list archives from 2003 and thereabouts.
Very little has changed in this area since mid-00's, people just rediscover and re-implement the same thing over and over again. Few get it 100% right (IMO) due to sticking to prediction being done client-side. That's inferior to the server doing it, because it gets you more precise timing and better prediction rate.
As a part of my work, I do UI/UX design for our products and post some snippets of the process to the development blog. Being able to show things _in action_ is a must, but I couldn't find a tool that was convenient for doing multiple back to back screen captures of the same sequence. Record, review, tweak this, change that, record again, review, rinse and repeat. Captures are short, so they must be perfect, so it usually takes a dozen of tries to get them right.
So I made a tool for the job. It is tailored to this specific workflow, but I think it's generic enough to be useful in other cases too.
I thought it'd be complicated, but it turned out to be dead simple - get the device context of the desktop, bitblt it on timer to a bitmap, draw the mouse cursor, see if it changed from the last time, save to the disk. Once the capture is done, go through the images and pack them into a GIF. The rest is just some UI work, to make things convenient, but out of the way at the same time.
For the reference, GifCam [1] was close, but it has palette encoding issues that create visible artifacts in the output. ScreenToGif [2] is a .Net app, asked to install 4.8, that asked to reboot the computer, etc. It also comes with a lot of extra stuff (it has a ribbon-style menu bar!) and requires quite a bit of clicking to get things done. Others were even worse off in comparison. So, as per usual, you want things to be done your way, you do it yourself.
So far I used LiceCap, but I like uGiffer more because it does its thing with less mouse clicking more keyboard shortcuts. It works well on Linux with Wine. Great job.
You want a benchmark that shows that one >>, one &, two [] and a + are going to be fast?
The test loop that wraps the lookup code will likely take as much CPU as what's being benchmarked. Even if you are to use RDPMC and even if you are to use it very sparingly.
The naive solution uses just one [], so it's reasonable to ask whether the compressed solution is faster. (Especially for the higher compression levels with even more memory accesses.)
And the relevant workload to benchmark wouldn't be just case-converting a single character, but a whole text, as would be done e.g. for constructing a case-insensitive search index.
Because most texts contain only a limited range of characters, it's entirely possible that a large lookup table works just fine because only a tiny portion of it needs to fit into the cache.
I'm fairly confident that since the lookup table fits comfortably in L1 cache, both algorithms will be about equally fast. You may see a difference if you have to case-fold the entire Library of Congress several times per user operation. The other case where there may be meaningful difference in performance would be embedded devices with small caches and slow memory.
Did an AB test a while back and mere presence of the PayPal option boosts sales through all other options plus generates extra sales through PayPal itself. Not something that I was expecting at all, but the confidence level was over 99%.