Personally I just don't use a banking app. The website works fine? I don't like the idea of having to use something from the Apple App Store or the Google Play Store, both companies of which could randomly decide I don't need to exist and cut off my access. ... no thanks? So I don't run "apps" at all. If your business is only available that way, sorry! But "I don't have a smartphone" tends to signal to the receptionist that they'll need to explain the myriad of other ways to do business.
KDE Plasma switched to Wayland by default sometime last year, and so far the main issue I run into is that a few screen recording tools I like stopped working. (Mostly simplescreenrecorder, which seems to be entirely unmaintained at this point.) Other than some initial instability with accelerated rendering on my GPU, which was quickly addressed, it kinda just works. I mostly don't notice.
Actually, GPU acceleration was why I initially switched. For whatever reason, this GPU (Radeon VII) crashes regularly under X11 nearly every time I open a new window, but is perfectly stable under wayland. Really frustrating! So, I had some encouragement, and I was waiting for plasma-wayland to stabilize enough to try it properly. I still have the X11 environment installed as a fallback, just in case, but I haven't needed to actually use it for months.
Minor pain points so far mostly include mouse acceleration curves being different and screen capture being slightly more annoying. Most programs do this OS-level popup and then so many follow that up with their own rectangle select tool after I already did that. I had some issues with sdl2-compat as well, but I'm not sure that was strictly wayland's fault, and it cleared up on its own after a round of updates. (I develop an SDL2 game that needs pretty low latency audio sync to run smoothly)
> Mostly simplescreenrecorder, which seems to be entirely unmaintained at this point
I use it extensively, it's easy to use, UI is compact but clear, works perfectly all the time. I honestly don't care that it is unmaintained at this point.
> KDE Plasma switched to Wayland by default sometime last year, and so far the main issue I run into is that a few screen recording tools I like stopped working. (Mostly simplescreenrecorder, which seems to be entirely unmaintained at this point.) Other than some initial instability with accelerated rendering on my GPU, which was quickly addressed, it kinda just works. I mostly don't notice.
FWIW, I have a KDE Wayland box and OBS works for screen recording. Slightly more complex than simplescreenrecorder, but not bad.
I've been using Kooha, but it's painful in a few ways, not least of which having aggressive compression that can't be disabled. SSR was nice because of the reduced time between "decide to record" to "draw a rectangle, done." OBS works, but is very clunky and cumbersome to reconfigure.
At some point I'll get irritated enough to seek out more alternatives and give them a whirl. Such is fate :)
The ability to own a TV at all, since even the cheaper sets now have this nonsense built right in. Loosely I think the idea is to subsidize the cost of the hardware with the marketing deals, but I don't actually know.
I am absolutely paid by the hour to learn stuff. The things I'm learning are mostly messy business domain bits: how does our internal API work, who wrote it, what were the constraints, which customer requested this feature, how much SLA will we lose if we break it to hotfix this CVE...
Yes the end result is at some small moment in time a thing that was built. But the value prop of the company isn't the software, it's the ability to solve business problems. The software is a means to that end. Understanding the problems is almost the entire job.
> But the value prop of the company isn't the software, it's the ability to solve business problems.
Clearly it's critical to the job, but to take your point to its limits: imagine the business has a problem to solve and you say "I have learned how to solve it but I won't solve it nor help anyone with it." Your employer would not celebrate this, because they don't pay you for the private inner workings of your own mind, they pay you for the effects your mind has on their product. Learning is a means to an end here, not the end itself.
Helpfully, neither is "I won't solve it nor help anyone with it" actually normal. That's what documentation, mentorship, peer review and coaching is for. Someone has to actually write all that stuff. If I solved it initially, that someone is me. Now it's got my name on it (right there in the docs, as the author) and anyone else can tap on my shoulder. I'm happy to clarify (and improve that documentation) if something is unclear.
Here, of course, is finally where AI can plausibly enter the picture. It's pretty good at search! So if someone has learned, and understood, and written it down, that documentation can be consumed, surfaced, and learned by a new hire. But if the new hire doesn't actually learn from that, then they can't improve it with their own understanding. That's the danger.
This weekend I'm working on a new song for my NES game, Tactus. I've been busy setting up the business and preparing for its first outing at a convention, so it was nice to relax and just create for a bit.
I used bubblesort on purpose in a game project. Specifically, to sort sprites in an NES game back to front, lazily, spending as few CPU cycles as possible. Bubblesort on the very small list (a dozen objects max), and early exit after the first swap. It eventually completes, and that was just fine. It's tiny, incredibly simple, and somewhat resilient to the list changing from frame to frame as objects spawn and despawn. Each partial sort makes some progress no matter what.
A few other algorithms would have fit the bill just as well, but bubblesort is perfectly adequate, so that's what will likely ship. More complex algorithms end up losing out due to greater initial overhead or larger ROM size.
The primary complication is that objects move around between frames, so the list doesn't stay sorted. Insertion requires a second scan once I've found an object that is out of position, whereas bubble can swap right away. (The candidate object is always N-1, after all.)
My goal is to stop working as soon as possible; this is a 1.7 MHz CPU and it has many other tasks to perform on a given frame. It's hard to appreciate unless you sit down to actually do it, but on a processor this slow, the scanning of the list and the comparison of depth is not cheap. It's computed on the fly as we go, there isn't spare RAM to cache it, and it changes every frame anyway. All of that makes the scanning and comparisons way more expensive than the eventual swap.
Insertion would be ideal here for a freshly spawned object, since we already know it is out of position and merely need to find its destination. (The work to shift the rest of the list down isn't super expensive, thankfully.) In practice this is already a big enough visual change that the player doesn't have much time to notice a depth error before it corrects itself.
There is "early exit after the first swap", which actually makes his algorithm closer to insertion sort than bubble sort. If the list couldn't change between each pass, it would be a very inefficient insertion sort in O(n^3) as you are constantly scanning the part of the list that is already sorted.
But this is a case where theory doesn't count as much as having an acceptable result. It is typical in video games, if it plays well and looks fine, who cares if it is incorrect. Here I guess that sometimes a sprite appears on top of another sprite when it should have been behind it, because of the early exit, but while playing, it turned out not to be noticeable enough to change the algorithm.
6502 can do it in one. 12 opcodes are glitched in a way that permanently halts the CPU, by causing it to never reset the internal tick counter (...sortof) that starts the next instruction. Recovery is only possible with a power cycle.
Sure. That also means it doesn't have to be kernel-level rootkits that fundamentally break the security model of my operating system and risk my bank account. Most people will be stopped by userland anticheat, right? It's inconvenient. So ... put it *there.*
And if someone does the kernel bypass thing, well, rely on server-side heuristics (which are imperfect, but also unknowable to the attacker) and you'll discourage enough of that with account bans.
Helpfully eSports players tend to have video captures of their gameplay, and most of these "undetectable" cheats are real obvious if you actually watch the footage. That catches most of the serious stuff at the upper level. It's why video verification has been a thing in the speedrunning scene for such a long time.
> Helpfully eSports players tend to have video captures of their gameplay, and most of these "undetectable" cheats are real obvious if you actually watch the footage. That catches most of the serious stuff at the upper level. It's why video verification has been a thing in the speedrunning scene for such a long time.
There's a subreddit called /r/vacsucks which is full of pro players blatantly cheating and getting away with it while the rest of the idiots think they're just good players.
Or, depending on your point of view, full of idiots flagging any player better than they are as cheating.
Aimbots can be "humanized" enough that any such determination becomes subjective.
Honestly this feels like the best possible outcome. It's pretty unusual for an appstore implementation to support multiple feeds[0], but it's great resilience to large company failures when they do. This way, users can totally still access Rebble's feed (and pay for a subscription if they like) just as before, but they are free to also use something else.
It is the *end user* who decides which feeds to trust, as it should be. And since it's built right into the app as a core concept, it doesn't take massive engineering effort to switch feeds if some sort of drama occurs.
[0] I'd normally call these repositories, but I've used Eric's term for consistency with the article.
Definitely agree that this is the best outcome for everyone! In particular, with multiple repo support, I'm hoping this can open the door for some kind of "F-Droid for Pebble" with automated builds from source repos. So many Pebble apps are open source anyway I think it would be a good fit.
Rebecca was well known in emulation circles for her high quality work on various games of the era, often pushing the hardware in unusual ways. This article is one of my favorites, detailing the wacky tricks she used to get Another World's 3D rendering system running acceptably on a Super Nintendo
She also somehow pulled off the port of Doom to the hopelessly underpowered hardware of the 3DO in just a few weeks, after others had tried and failed for much longer than that. The final release had a reduced viewport and a bad framerate, but the background music was great (recorded with a band and stored as audio tracks on the game CD).
Also, 62 years is much too young! And one month from diagnosis (because of being short of breath) to dying is really rough - although there's a lot of progress on cancer treatment, some forms have symptoms at such a late stage that they're unfortunately still a death sentence...
I will never get over the company CEO sending here PNGs of new weapon models and saying, essentially, "Yeah so you can just copy & paste these into the game, right?"
Back when Blizzard was still Silicon & Synapse, we got Rebecca's source code to Another World SNES from Interplay to use for a game we would develop, and they would publish, and I was the engine programmer.
I remember reading the source code, which was ... sparsely documented, and wondering what was going on. Like "you're writing to the DMA registers?!?"
The code was amazing, because it has has to draw polygons into 8x8 pixels cells that are stored in planar format at 60FPS. On a 3.5 Mhz processor. Blew my mind.
Incidentally, the game was called "Nightmare", and later became "Blackthorne", which was released for SNES, Genesis, and PC.
reply