There’s considerable precedent for seeding IP lists or using stealthy tactics (e.g. imagine how it’d be trying to block something which searches Google or Twitter, hits a random ad network).
Fair enough. On the other hand it can also prevent users from stumbling upon malware distribution sites by both blocking them directly and secondly blocking advertisements that often link to malware.
All of this of course is part of defense in depth, multiple layers of incomplete protection is better than nothing at all.
Oh definitely, I'm not saying that there's _no_ benefit — the key point is the distinction between something which you control to something you don't. DNS filtering is good for clients you control but it's important to understand that you can't force malware to use it to avoid accidentally thinking that you're protected against other threats (which I've heard various times from people who should know better but weren't thinking about it carefully in-depth at the time).
It definitely lends credibility; versus the introduction from the other comment - that this is the guy that glitter bombs package thieves on youtube - which makes me take this less seriously.
I'd recommend watching those videos before knocking him for the glitter bombs. They are impressively engineered, with entertaining videos which contain a good deal of detail about how, why, and in the most recent version, how they are working with law enforcement to crack down on package thieves.
"Stuff Made Here" is amazing. I can't believe how talented that guy is. And he seems much less edited/fake than Rober (who I also enjoy). I watch both of their videos whenever they upload a new one, but "Stuff Made Here" appeals much more to my engineering side, and I appreciate the lack of "showmanship" that is so prevalent in Rober videos.
Rober cuts to the chase. I think it's tuned for a different audience. "Stuff Made Here" guy is willing to show all of the "wrong turns" on the way to a good design. Rober's audience doesn't get a chance to get bored with one of those wrong turns and change the channel. But "Stuff Made Here" will attract an audience that is curious about the process that got him there.
Those packages are designed incredibly well, IMO. There's a lot of things that can go wrong and he seems to reliably get footage of it being opened and recovers most of the packages, too.
Wsl 2 is really cool, right up until you want/need to do anything with the underlying hardware. No usb passthrough, no hardware acceleration, gpu passthrough is there but it's still early stages as performance is about half of native and vendor tooling is absent, etc
It's getting better all the time though - they tease usb passthrough might be doable as it's already supported with remote desktop
Yeah it's actually pretty damn good. Performance was better than it was with WSL1 for me, at least (especially IO). IIRC they are exploring USB passthrough using Hyper-V sockets, but it's still very early to actually talk about having that included[1]
Once they figure that out I might just as well be able to switch over and stop dual booting. I hate dual booting more than I hate Windows, so it would be an improvement.
Probably, but it also introduced a lot of edge cases for compatibility issues. I thought it was a reasonable approach, though likely took more devs than just supporting the more tightly integrated VM environments.
I will say that Docker Desktop works MUCH more smoothly with WSL2 than the prior approach.
About the only issue I see now is about once a month I have to reboot because the magic localhost port mapping between docker, wsl-ubuntu and native host goes wonky. It's not so bad as long as I realize before diving into a rabbit hole to figure out why I can't connect to something.
WSL1 was more or less the reverse-equivalent of WINE as I understood it, more or less a translation layer for a subset of syscalls, the approach is awfully limited from the get go. Not sure how using a VHDX or partition would solve that. We'd be back to square one, with things like containers being unusable again.
> Not sure how using a VHDX or partition would solve that
The problem with WSL1 is limited to disk IO performance, because the compatibility layer that's easy to do with system calls isn't so easy to do with the filesystem.
> We'd be back to square one, with things like containers being unusable again.
It's complementary. WSL2 when you play with containers, WSL1 when you don't.
Personally, I don't bother with containers for about 90% of the development cycle - and it's just for testing before being deployed to a genuine linux, not some VM.
Also, if you want to run servers with WSL (say, postgres), having containers is the last of your problems.
Ah, different usecases then. I pretty much tend to go containers from A-Z for anything non-trivial, thus WSL1 was more or less useless for me. IO is also a big problem, just running a simple git status on a bigger project is a PITA.
I wouldn't call having only a subset of system calls, no containerization, no background services, no proper init system, no kernel modules, "not all that limited". But maybe that's just my use case.
I've never hit a system call I wanted but wasn't available on WSL. In fact the couple times I've been disappointed at the lack of a system call it was when I was booting linux.
No containerization: Agreed, this is a significant limit.
Background services work just fine, I don't know what you're getting at. I have cron and stuff going.
What's improper about the init system? I start services, I stop services, it seems fine.
No kernel modules: I feel like this is pretty niche.
There was a story a few weeks back about Microsoft working on a new android subsystem. So truly coming full circle; android OS stability (via project treble), the vm approach instead of compatibility layer approach, and improvements to hardware sharing/passthrough to wsl 2 mean that they can finally realize what they tried to do with Projecy Astoria.
They'll need to manage their own app store as I can't imagine they'll have gapps//shims out of the box, but that works in their favor if they wanted to do another mobile play.
They'll need to manage their own app store as I can't imagine they'll have gapps//shims out of the box, but that works in their favor if they wanted to do another mobile play.
When the new EU fair market regulation is accepted, they will be able to compete with an app store op Android (or iOS):
allow the installation and effective use of third party software applications or software application stores using, or interoperating with, operating systems of that gatekeeper and allow these software applications or software application stores to be accessed by means other than the core platform services of that gatekeeper.
Since they already allow alternative app stores (e.g. Steam) on regular Windows, not much changes for them in this respect. But they will also be able to compete with the Play Store and iOS App Store with their own store.
It's already possible to have other app stores than Play Store on Android, even simultanously. I think some features are reserved to Play Store in practice (to stores pre installed on the phone) so there could be some improvement on this point.
Google also currently prevents OEMs from installing competitors' stores by threatening to withhold access to Google's services. This is one of the points in Epic's lawsuit.
At this point I could see how some developers may prefer an MS store for ios and android devices over the native stores. Especially if they make deeper cuts on pricing (10% of sales instead of 30% and 3% of transactions instead of 30%).
I'm slightly leery about it all, but definitely warming up to MS this past decade. WSL2 and VS Code have made my life much easier to say the least. Of course this is the intended effect, I no longer have the urgency to get into a full Linux environment this way.
On-Topic: glad to see this GWSL thing, as I'd been thinking about doing similar... getting X and pulseaudio working in windows, and configured right in WSL environment is a pain to say the least. If this eases that pain even if only for local logins, I'm pretty happy with it. I spent a couple days trying to get it all working... I could launch Ubuntu's Firefox instance, but couldn't for the life of me get audio working right and just gave up after a couple days.
>They'll need to manage their own app store as I can't imagine they'll have gapps//shims out of the box, but that works in their favor if they wanted to do another mobile play.
They own App Center so maybe its not that far away.
The difference there is that the pausable SVG is embedded on the page as an object element. There is Javascript inside the SVG document that is enabling the replay to be pausable.
Github readmes however only allow embedding SVGs as images, and Javascript won't work in that case.
As i understood it, using raw input keeps the system awake and that may be working as intended (hence they suggest that Microsoft better document that//reflect it in powercfg /requests). The issue is that GeForce experience was requesting raw input when it wasn't necessary.
As i understand it, she was supposed to submit to google for an internal review a fews prior to externally publishing it. She simultaneously submitted and published it, and Google sought a retraction after internal review. She met that with an ultimatum with do X or I'll quit. They took that as a resignation (as Google wasn't going to do X), and accepted it.
I'm not fully informed about what she wanted, but I don't think it was particularly unreasonable, the controversy more has to do with headlines and spotlights about this person and her conduct/history in the past.
It did, but only for a small portion of applications. Others would run very poorly, if at all, depending on the degree in which the application hooked into google services//android api. The original project was more analogous to WINE for *nix systems, a compatibility layer; there where many edge cases that simply didn't work and supporting new versions of Android would require almost completely rewriting it (pre project treble).
The VM route is simply more workable and sustainable. While WINE has achieved some great success, it's still a spectrum. Some software simply doesn't work, some mostly works, some works but performance is abysmal, and some work flawlessly - depending on how deeply they integrate with windows and what APIs they utilize.
WSL's origins are actually as a android subsystem for when they where making a mobile play with the Windows Phone. At the time it ultimately got scraped because it was too ambitious of an undertaking, and got spun off as WSL. Now that android[0], windows OS and WSL[1] are more mature it's going full circle.
[0] maintaining an android subsystem (and various versions as distros) should be easier now for the same reason it's easier for vendors to update phones, project treble.
[1] better filesystem sharing, GPU pass through, WSL is close to natively supporting graphical applications, etc
I don't have a good source at hand, but there was even a preview version of Windows 10 Mobile available that had support built in. You could get it from the insider program. Now that the whole ecosystem gets wound down it becomes incredibly frustrating trying to revisit those old systems. You can easily recreate installs of Windows 98 or XP in various flavors and patch levels, but for Windows Phone this has become mostly impossible.
For example, the store for WP8.1 and older has shut down, so you can no longer get the app for upgrading to 10. There was a tool released by the end of 2019 that can do it via USB, but that stopped working in October since the server it contacts now requires TLSv1.2, and the tool was written in .NET 4 which doesn't do 1.2 by default. So there is a registry hack you can use to enable it again, until eventually that doesn't work anymore either. There are inofficial, incomomplete mirrors of some device specific factory images, and the pretty awsome "windows phone internals" tool for rooting and modding some devices, which was mostly a one man show.
With said tool and a lot of patience, it should still be able to get one of the two insider builds of win10mobile running that had android emulation, given you find the instructions, all the files and images required. And then it's still only an alpha version that emulates the Android 4.4 API.
I have a friend whos working on software archival, so through him I became aware of the importance of trying to preserve these kind of things, and those very closed and additionally niche platforms are the second hardest thing to preserve, after cloud services.
It's been a good while since I read the original story, but Wikipedia [0] has some background and should have some citations if you want to dig in further
