MGBA Integration: Introducing the Integrated GBA
4 points • 0 comments
Recent @rossy Activity
MGBA Integration: Introducing the Integrated GBA
4 points • 0 comments
I'm sorry, but I find that hard to believe when the linked posts are from a Microsoft employee, who says repeatedly that the problem isn't a simple as "NTFS is slow," that they spent a release optimising NTFS, they've gotten rid of all the low hanging fruit and so on. I don't see why they'd be making excuses for NTFS when the underlying problems seem to be much more fundamental to Windows, which is much worse. You say you discovered the MFT contention issue when you were working on Subversion a decade ago, but these posts are from 2018, so I'm inclined to believe that the MFT contention issue has been mitigated and the real issues really are things like filter drivers, like they say.
I'm also not sure there's two paradigms here, if by that you mean there are workloads more suited to Linux and workloads more suited to Windows. Are there any file system operations that are actually faster on Windows? I'm still inclined to believe, like they say, that "file operations in Windows are more expensive than in Linux," even if large files are less impacted than small files.
I really hope Microsoft can improve this, rather than just throwing it under the rug and saying to use Linux VMs, even if they have to make drastic changes like deprecating filesystem filter drivers completely. I think a lot of us depend on the performance of software that was designed for fast filesystems and ported to Windows (not just Git, either.) I also think a lot of tasks fundamentally use a lot of small files. After all, what is source code?
> Well it should 'just work', Hit the download button, install, plug it in and forget it.
That's exactly what it does. When software like this is packaged, the maintainer will normally place a dependency on any other software that's required for it to work, like ratbagd. ratbagd is a D-Bus activated service, so it will be started automatically if any program tries to use it. The result is that a normal user should never see the error message.
> No terminal command copy pasting or config editing like this user. 
Unfortunate for that user, but I can report it works fine for my (wired) Logitech G303. The comment said he couldn't get it to work back in [the] day, so it might have already been fixed.
> Again the reason why people continue to use Windows.
Please don't bait OS flame wars. I doubt anyone chooses their OS based on its ability to change the DPI of their gamer mouse, but this seems to be a nice piece of software for those of us who have a reason to choose Linux. It's hardly the fault of Linux or libratbag that the manufacturers of these mice have chosen to use proprietary protocols and non-cross-platform software for configuration.
It's possible that the driver software works in Wine, but I'm not about to test. I don't even like installing horrid gamer drivers on Windows.
> That is enough to confuse them and start googling around for that message.
I'm struggling to think of a reason why that isn't a good thing. God forbid an error message gives you something googleable and actionable rather than something cutesy and meaningless.
It's only common in certain bubbles. Someone who primarily uses FOSS could easily say this. Someone who prefers software created in the era before online telemetry was widespread could also say this.
It wasn't a banking app, but I recently came across the first app I've seen that, in addition to SafetyNet, also checked if the Magisk Manager app was installed to try to detect if the phone was rooted. I wouldn't be surprised if it was for this purpose.
I bought one of these (WRT1900ACS) when I was working from home last year. It's good, but not great. Before anyone else buys one of these for their open source "support," you should know that Linksys/Marvell basically threw a buggy open source WiFi driver over the wall, failed to upstream it to the Linux kernel due to issues with the code, and abandoned it.
Although it works fine for my simple purposes, there's a discussion of some of its issues at the end of this PR: https://github.com/openwrt/openwrt/pull/2397
Oh yeah, I was floored when I plugged a DS3 into my Linux laptop and the KDE UI came up prompting me to pair the device over Bluetooth. Sure enough, I unplugged it and it seamlessly switched to Bluetooth. That was a level of integration I wasn't expecting, and without ever installing any DualShock-specific package.
Unfortunately, one of the reasons I bought the controller was to try out the pressure sensitive face buttons, and PCSX2 on Linux didn't seem to support that? On Windows, PCSX2 can do this with ScpToolkit, but that seems to be abandoned. Still, for the 99% of games that don't need pressure sensitive face buttons, the DS3 integration in Linux was literally perfect.
This is bad news. I think a lot of businesses are suspicious of LE and itching for valid reasons to keep the status quo of paying for certs, and well... here's one. I've been pushing internally for my business to use LE certs, but maybe I'll stop, since we still have users on Android 5.1.1-7.0.
I wonder if this is something Google could fix in Chrome without needing an OS update. They are apparently a major LE sponsor.
You'd be surprised at what image processing algorithms are fast enough to work in realtime when they have optimised GPU implementations. Anime4K is one of those CNN-based anime upscaling tools, and it can run in realtime as a shader in mpv. (I'm not a fan of those upscaling tools myself, but I don't see why they couldn't be used in emulators, for the people who like them.)
I think it might be an out-of-date assertion, but I'm not sure either since I also hear it from people who seem to be well-versed in the C standard. The only place in C17 where I can see memcpy singled out (6.5p6) also mentions copying "as an array of character type." The definition of memcpy itself just describes it as copying characters. It's true that some types can have bit patterns that are "trap representations," that is, they cause undefined behaviour when used, but memcpy can also create trap representations. You could memcpy to copy the bit pattern of a signalling NaN from an int into a float, for example.
memmove on the other hand can't be implemented in standard C, but it can be implemented on most platforms using only implementation-defined behaviour, because casting a pointer to an intptr_t is implementation-defined, but on most platforms with a flat memory model, it gives you the linear memory address.
> memcpy actually has a few semantics that cannot be legally expressed in C (specifically, strict aliasing doesn't kick in).
Are you sure? I hear this a lot, but I don't think it's really true. char pointers are allowed to alias pointers to any other type in standard C (C17 6.5p7,) so unless I'm missing something, a correct C implementation of memcpy could just cast both its arguments to char pointers and copy them char-by-char.
I agree with your premise that the call to memcpy() is undefined, but I think that's entirely because of the conflicting definition, and has nothing to do with any special semantics of memcpy, so it would equally apply to any other standard library function.
While similar in concept, Wine is better than WSL1 in a lot of ways due to supporting sound, graphics, and GPU acceleration.
I've always been suspicious of WSL because it follows a narrative that benefits Microsoft - that Linux is primarily a command-line/server environment, and the graphical and audio applications for Linux are not worthwhile. It doesn't have to be like this. WSL1 was based on an Android environment for Windows Phone called Project Astoria, which did support graphics.
I think that's a proprietary in-house emulator known as POPS. The fact that Sony already had an in-house PlayStation emulator for the ARM-based Vita makes their decision to use something else for the PS Classic a bit strange.
I don't know about you, but I've been running wobbly windows up until about a month ago, when I disabled KWin's compositor in favour of picom for performance reasons. I hope to get them back when I'm able to start using KWin on Wayland.
Hmm, poking around on that website, there's some more:
That tarball seems to have fallen off the internet, but there's also this. Check out laserbits.txt. I wonder if that's the data.
> While folks are thinking about CDs: I've not been able to get an F2/F3-frame CD image. If anyone has such a thing (not copyrighted, just a CD containing a text file or public domain music piece is fine), I'd love to get it so I can implement a CIRC encoder/decoder!
I don't know if you've already seen this, but I've heard of someone getting an image like this. They used it to discover what the AccurateRip drive offset values mean in terms of the physical location of the subchannel data and interleaved main channel data on the disc. There's a vague description of their process in there as well.
> Using my neat hardware setup I now have captured a precious 0.1 seconds worth of 588-bit channel data frames from a pristine audio CD, each frame containing, among other things, a subchannel byte and 24 bytes of audio data.
> I can reproduce the CIRC, get the de-interleaved audio data, and also do the Reed-Solomon C1/C2 stuff in software from my analog laser readouts - showing an error-free read, identical to what I get with my Plextor using somewhat more conventional methods.
There's a good list here: https://en.wikipedia.org/wiki/List_of_albums_with_tracks_hid...
I was using Arcade Fire's Reflektor as a test disc for this a little while back.
That's cool. I didn't know that (I've never used one before.) Maybe it would make more sense to do the original GBA then. The SP frontlight has a bit of a blueish tinge to it.
Yeah, writing homebrew to get the GBA screen to display whatever a screen displays under a colourimeter, and getting that to work with the actual colourimeter might not be so easy. I think getting a device profile for the frontlit SP would be the most interesting, since I've heard it produces colours more like the original GBA than the backlit one, but maybe a colourimeter designed for backlit PC monitors would have trouble with it. I don't think performance would be an issue though. mpv can do colour management in real time by generating a LUT from the ICC profile and applying it to each frame with GPU shaders.