meekins

Although if you want to play the same game you played 20 years ago today, running it on Wine is your best bet to get it running.

The rendering won't be 1:1 but installing the most common MS fonts already does a lot

Due to its simplicity it's a fun little processor to program. Hacking on some assembly on a ZX spectrum emulator is a nice way to stay sane in this high abstraction LLM age.

It also supports proxies which is important to some corporate back-end scenarios

Really excited about this! At least in Sublime Text I've found multiple cursors a really powerful tool for ad-hoc transformations on snippets of semi-structured text or instantly and visually applying the same edit on multiple similar lines.

Please recommend a troubadour who knows the Neat Records, Guardian Records n' Tapes and Heavy Metal Records singles catalogues and I'm sold :)

The comment was especially about TypeScript. Unlike the ancient JavaScript versions best used for web sugar you're possibly thinking of, it's a highly pragmatic and well designed general purpose programming language with an unique and very powerful type system.

This is what I've done in those rare cases I've had to fix a bug in a tool or a library I've used professionally. I've also made sure to do that using online identities with no connection to my employer so that any small positive publicity for the contribution lands on my own CV instead of the bureaucratic company getting the bragging rights.

Developer-specific sandbox environments with hot code reload is the golden standard here but Localstack is great if you can't do that due to (usually IT deparment-related, not technical) reasons.

As someone with years of experience on serverless stuff on AWS I might be a bit biased BUT I'd argue serverless is the sweet spot for most applications. You need to remember however that most applications aren't your typical startups or other software products but simply some rather boring line of business software nobody outside the company owning it knows of.

Concerning how IT departments in most non-software companies are, the minimal operational burden is a massive advantage and the productivity is great once you have a team with enough cloud expertise. Think bespoke e-commerce backends, product information management systems or data platforms with teams of a handful of developers taking responsibility for the whole application lifecycle.

The cloud expertise part is a hard requirement though but luckily on AWS the curriculum is somewhat standardized through developer and solutions architect certifications. That helps if you need to do handovers to maintenance or similar.

That said, even as a serverless fan, I immediately thought of containers when the performance requirements came up in the article. Same with the earlier trending "serverless sucks" about video processing on AWS. Most of the time serverless is great but it's definitely not a silver bullet.

The 4.x series was the one where the ideas still making Plasma so powerful were seeded. While I loved KDE 3 the design for 4 seemed revolutionary. Too bad it was alpha/beta quality up until the 4.6 release years later. I fared through all the bugs, crashes and performance issues with a young student's determination (while running Fluxbox on the side) but I can very well understand people doing serious work had limited patience for the issues.

Anyhow, happy anniversary from a long-time KDE user!

Smartphones?

In a sense the simplicity of SLS is a trap: immediately when you need to move past the synchronous lambda invocations via API GW use case (caching, service integrations, step function workflows etc) you need to either fall back to plain CloudFormation or rely on third party plug-ins with possible problems with maintenance, quality and feature-completeness. This makes it a difficult choice to recommend beyond simple use cases.

In an AWS scenario I can think of:

Pro vs pulumi: you get a declarative template to debug and review

Pro vs CDK: The declarative template is applied via APIs instead of CloudFormation. The CDK CloudFormation abstraction leaks like hell

Same story with Azure. All the good services are acquisitions, rest is low quality feature catch-up with AWS augmented by a terrible IAM system.

KRunner [1] on Plasma is pretty awesome. Plenty of plugins available [2] and it's also very useful out of the box on most distributions.

[1] https://userbase.kde.org/Plasma/Krunner

[2] https://store.kde.org/browse?cat=628

I loved the folder view! It really highlighted the shift to a modular design in Plasma and solved the problem of desktop eventually ending up as a garbage dump of stuff that at some point was relevant but now impossible to find by providing configurable views to files that exist elsewhere and can be adjusted to fit current needs.

The 4.0 release was otherwise painful though as it was a slow, constantly crashing mess of bugs. At around 4.3 it became stable enough to serve as the primary desktop but IIRC that took years and I saw a lot of friends adopting Gnome or XFCE.

Overload is awesome! However I wonder if some remnants of 90s game design like tight time limits and repeating enemy ambushes that make the game such a familiar and intense experience for the old school in reality disadvantage the game and the genre from reaching wider audiences.

There was also another classic Descent contender, Forsaken, that got remastared in 2018 to run on Linux and macOS in addition to modern Windows platforms. The original game was actually used as a graphics benchmark for early 3d accelerators due to its lighting effects.

That said, looking forward to playing Descent 3 on a modern platform!

The only Windows box I have is an AMD-based gaming rig and last time I checked the hardware isn't Windows 11 compatible. Time to check out how the gaming experience on Linux is these days.

It would be awesome to see Git becoming decentralized again but what's the likelihood of GitHub implementing this?

My current primary workstation is very low spec and old compared to a M2 Mac. On that machine Sublime Text is very performant and provides an awesome code writing experience through LSP. I use it as a daily driver with TypeScript, Go and Dart. I try out IntelliJ (or Android Studio) and VSCode occasionally to check out how they are these days but they feel sluggish in comparison.

If you need more IDE-like features like running tests and builds or managing for example mobile phone emulators from the editor it requires more fiddling with configuration and plugins but is doable.

The CoC doesn't ban supporters of specific political agenda or party line but it is a banned topic. Anyone who's been on the internet in the past few years knows how passionate these supporters can get. That's a magnet for heated political discussion that very quickly gets uncomfortable for everyone else. It's impossible to be inclusive to certain minority groups while allowing promotion of politics directly against them.

If they wanted non-sanctioned editors integrating Copilot they wouldn't have taken the extra steps of implementing an obfuscated LSP but provided an API or a plain client library. At best this could be a pet project by a Neovim fan GH employee. Either way I wouldn't expect long term (if any) support from this thing.

It's interesting that the #2 selling point on the landing page (the Copilot integration) relies purely on Microsoft's goodwill. There is no official API for Copilot but instead a (non-standard) LSP implementation embedded into the proprietary Copilot Neovim plugin. Zed seems to trust under the hood that a release of the plug-in exists on Github, pulls the minified-js language server from there and integrates with that. The minute MS decides to pull the plug on the Neovim plugin Zed loses the functionality as well.

I wish we had a proper API to interact with copilot but it seem that pulling everyone else except the dedicated VIM and JetBrains users into VSCode land seems to be more in their interest.

It's a sad world when a thoughtful, well-structured, obviously experience-based and informative comment is immediately assumed to be word guessing machine generated garbage.

This is very disappointing after migrating to Insomnia from Postman a couple of months ago. I did the migration even when my company provides Postman licenses for the employees because I don't need nor want the "collaboration" features, cloud sync (I have my backups covered, thanks) nor the telemetry.

Can anyone recommend an open source API client that is content being just an API client?

Eric Evans: Domain Driven Design

The vocabulary might seem foreign today but the concepts are as crucial as ever in the world of modern microservices.

It's a great relaxation language for hobby projects. After a day of cranking out tight functional style Typescript at $DAYJOB it's refreshing to work in a "stupid" language where the space to search for the most elegant solution is rather limited. You're just telling the computer what you want it to do in a very explicit and plain way.

Serverless runtimes don't shut down the instance immediately after the invocation is complete but keep it up for an undetermined time depending on many factors (usually ~15 minutes) in order to process a possible new event without the start-up overhead (cold start). This means that in a system with constant traffic some instances may have a surprisingly long uptime. The instance gets destroyed when it throws an error though so a function with a disabled GC would clean the state when it runs out of memory. Slower processing done by memory-starved instances would probably eliminate any minimal performance gain you could get by disabling the GC though. (EDIT: I just realized that with no GC desperately spinning in place the starvation would not have much performance impact so this would actually be a very interesting approach if you can tolerate some invocations erroring out on out of memory errors, sorry!)

In regards to performance optimization of Lambdas, start-up time is the most important factor as cold starts happen also in cases of concurrent requests when no warm instances are available. This means that Go, Node and Python are pretty sweet for serverless. Thanks to recently released Lambda SnapStart feature that launches new instances from snapshots taken after application initialization Java (even with DI frameworks) is a plausible option if you're inclined that way. Previously you had to use a custom runtime and AOT compilation (that rules out any runtime DI stuff) to achieve tolerable performance with Java on Lambda.

I stopped using the Severless framework when CDK came out. For simple cases it's still fine I guess but a lot of time I found myself falling back to plain CloudFormation (ugh) or relying in plugins with questionable maintenance status. I would not recommend it for new projects and even AWS SAM makes applying some best practices like least privilege principle easier.