Lorkki

This seems like a fairly gentle introduction. I will definitely consider it as a starting point for more junior developers interested in touching our Rust code.

For those with more experience, Rust By Example walks through the same concepts in a more compact form that also lets you experiment with the code in your browser: https://doc.rust-lang.org/rust-by-example/index.html

Steam doesn't require use of its DRM either, and it's well-known that several titles don't have any: https://steam.fandom.com/wiki/List_of_DRM-free_games

"Compression" is probably just poorly chosen wording. This has more to do with reducing the number of required samples in applications like eye-tracking VR, where you can choose to render a dense image for the part that the user is looking at, while reducing detail in peripheral vision. Current implementations use some fractional resolution(s) for the periphery and blend pixels using more traditional methods, which results in blurryness and/or aliasing artifacts.

The timeline checks out though. The Macintosh came 12 years after the Alto was conceived, or 16 years after Engelbart's NLS.

Seafile has been working for me as a personal Dropbox replacement, with s3ql for mass storage. It's very light in relation to Nextcloud/Owncloud (a primary criterion for me trying to cheap out on servers), supports WebDAV, role-based access and a bunch of SSO options. The biggest possible drawback I can think of is that it doesn't store files in the plain, so you can't trivially tie in SFTP or serve files from the storage directly.

The parent's point wasn't about CLI vs. GUI so much as different ways to present and design programs. Most people these days write software in an editing environment that's much richer than the TTY.

Again, two different things - ending an existence, versus there being no existence to begin with.

Conflating the two makes one argue ethics from a realm of infinite possibilities instead of focusing on reality, which doesn't really make for great moral choices. For instance, should people have as much unprotected sex as possible, without any regard to their or their offspring's well-being, just to give the most children the chance to exist?

> Without such testing, they wouldn't exist at all. So, is a life of, maybe okay but maybe awful lab testing better than none at all?

There's no experience of any kind related to not existing in the first place, so the two options are completely orthogonal. It's like asking whether you'd suffer from your parents never having met.

So do all the implicit assumptions in duck-typed code, but following them relies fully on the programmer's own caution.

You can of course add explicit checks and tests, eventually paying the same amount (or more) in LOC as the typed implementation's initial cost, but then you're also tasked to keep those up to date, without the compiler's aid.

> The one part I disagree with is necessarily using <table> in place of divs with CSS Grid.

I suppose the soundness depends on how you read the word "table". For actual tabular data, <table> is probably the right choice for accessibility reasons. It's also why it's usually a bad idea to abuse tables for grid layouts in other cases.

Technically, the barrier to entry is as low these days as any other messaging service: you can sign up on IRCCloud and instantly have a friendly browser-based experience without worrying about setting up a persistent client, logging etc. by yourself, and mobile and desktop clients are available.

These days the network effects just favour old farts and engineers.

That's really not different at all from any other operating system. The "laypeople" in court have previously been perfectly able to consider even highly integrated OS components as separate from the whole - such as Internet Explorer in the case of the big old Microsoft antitrust lawsuit.

I think that a more likely reason is that Apple have plans for macOS that wouldn't play well with GPLv3's anti-Tivoisation measures.

> There is a risk that simply including or using bash4+ could infect the system with GPLv3 compliance requirements, forcing Apple to publish their proprietary source code.

This seems dubious, since the FSF themselves make the statement that aggregates of differently licensed software are fine, as long as you comply with GPL for the GPL-licensed parts: https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation

Of course it does. But in the context of computing equipment, the computer game series was the first thing that came to my mind. Nuclear fallout is in a different domain.

"Fallout" also seems like a particularly bad choice of name to sell this vulnerability by, since the game series is so well known.

(I would also prefer descriptive names rather than this kind of marketing, but these are the times we live in.)

The way you present things at the footer does makes it sound like you're simply asking for an email subscription. It might help to be more open, ie. "this book is a work in progress", and to display the price before asking for contact details.

The official VS Code snap is unconfined, ie. it only uses snap for package management without the sandbox. This means it can access the settings stored in your home directory just the same as if it was installed through apt.

Snaps with strict confinement can also ask for home directory access as a specific permission.

As always, the solution would be to not attempt to support "Linux", but to pick one distribution (or a manageable set) to support officially.

It's a lot smoother than stable RLS, but type resolution is practically nonexistent for futures-based code due to trait support still lacking. Definitely excited to check back once that's resolved though.

Yep, it seems built to run on NEOS, which is an Android distribution: https://github.com/commaai/neo

It may help stave off blatant rip-offs for a while.

Of course, if you strike it big, someone will eventually find enough time with a debugger to get around it, but as a small indie dev you'll probably be most interested in making sure you can break even first.

I don't think I've seen any software for many years that would target the latest non-LTS release. If anything, it's more typical that proprietary apps fall out of date and require obsolete packages from an LTS that's no longer current.

I don't remember how long it's been the case, but these days LTS is the first option that they show you, and it's clearly marked as such: https://www.ubuntu.com/download/desktop

LTS releases also don't offer upgrades to non-LTS versions unless you explicitly enable that via the "Software & Updates" tool.

Right now the main disadvantage is that GNOME Shell is single-threaded, and handles not only those JS extensions, but also essential tasks like window compositing. This means that a misbehaving extension can freeze the whole desktop, which is especially bad on Wayland where that includes the mouse cursor and input processing.

I still prefer GNOME for the rest of its UX, but if you ask me, the next rewrite can't happen too soon.

Edit: I noticed that some of the new improvements seem to be addressing just this, so what I'm saying may be out of date in regards to the latest version.

Staying with the LTS release is a perfectly valid choice if you want a slower pace of changes.

Isn't inotify meant for exactly this kind of thing, though? You are already introducing a hard dependency on Linux syscalls in "v4" of the optimisations, so it would seem advantageous to make use of that to avoid the full directory traversal for most of the time.

> Furthermore, dumped-over-the-wall projects like Android would be better referred to as "Shared Source" (with its association) - the Free branches are seemingly unable to actually keep up with the master!

That's because AOSP by itself is Android without all the integration work that's necessary to make a useful image for a specific device, and traditionally it's been a lot of work for each new version. Things are better in that respect since Android 8.0, which I think shows in frequency of both manufacturer updates and community builds.

We have the parliamentary election coming up soon here in Finland, and the roadside is currently littered with ads that prominently feature candidates and their numbers, very cleanly printed and often on a nice solid colour background. There have been stories in the news that this has caused actual problems with the current speed limit detectors, especially when the numbers happen to be even tens.

So a warning-only approach definitely seems like the right way to go for now. Possibly with a manual option to either dismiss or accept the hard limit.

Besides Zink, there is GL ES support on top of Vulkan through GLOVE[1] as well as Google's own ANGLE[2].

[1]: https://github.com/Think-Silicon/GLOVE [2]: https://github.com/google/angle

Most of those are either very straightforward subtractive synthesizers, or use digital FM synthesis. It's much more efficient (and accurate) to start from sampled basic waveforms or reverse-engineered data from the actual systems, rather than building them using additive synthesis techniques.