c0ffe

I used to like D too.

At the time there was an alternative standard library called Tango that was more object oriented like Java or .NET, combined with a desktop UI library (desktop apps were my focus at the time) that was similar to .NET's Windows.Form (I think it was called DFL, and surprisingly the site seems to be still online [0]), plus the native speed & simple approach of D1 I really thought it was going to stay relevant for years.

Sadly, then D2 appeared, the community fragmented over time, then Tango was disbanded, and at some point I think I moved on to web development with Flash.

[0] http://www.dprogramming.com/dfl.php

This leaves with a bit of concern about how reliable is storage encryption on consumer hardware at all.

As far as I know, recent Android devices and iPhones have full disk encryption by default, but they do protect the keys against random bit-flipping?

Also, I guess that authentication devices (like YubiKey) are not safe and easy to use at the same time, because the private key inside can be damaged/modified by a cosmic ray, and it's not possible (by design) to make duplicates. So, it's necessary to have multiple of them to compensate, lowering their practicality in the end.

Edit: from the software side, I understand that there are techniques to ensure some level of data safety (checksumming, redudancy, etc), but it thought it was OK to have some random bit-flipping on hard disks (where I found it more frequently), since it could be corrected from software. Now I realize that if the encryption key is randomly changed on RAM, the data can or becomes permanently irrecoverable.

I understand that Fuchsia is currently targeted at IoT or consumer devices, but can it run "containerized apps" in server environments with its current design (compared to Linux namespaces)?

Maybe Kubernetes can be extended later to support Fuchsia nodes. It sounds really interesting to have a new target OS, with a different network and virtualization stacks.

Compiling every dependency into a single WASM binary (including database engine, language runtime, etc) and just deploy and scale it on a serverless platform.

No more containers to develop or to deploy, and eventually, no UNIX filesystem around the runtime.

The last time I had to work on a Gatsby project, it had build times of approximately nine hours.

Last thing I heard from them, is that when faced with the need to update news on the site more quickly (not on realtime, but "sooner"), the development team had to make a separate mechanism to query the news from the backend when the site was running on the browser, instead of doing it at build time, using the builtin GraphQL database. This defeats the central idea that everything on Gatsby comes from a central data source.

Check PulseEffects, it has an UI that allows to enable and configure effects for both input and output. Last I checked, it is on the default repository of many distros.

https://github.com/wwmm/pulseeffects

I agree: plain text is after all, easier to manage.

Personally, I've used Joplin [0] some months ago, and Im using QOwnNotes [1] now. Both are open source, cross platform, and can synchronize with Nextcloud. QOwnNotes may feel a bit faster since its written in Qt/C++ (Joplin is an Electron app).

However, I still find hard to write tables in Markdown manually.

[0]: https://joplinapp.org

[1]: https://www.qownnotes.org

I would like to add Bootstrap to the list, including other CSS libraries/frameworks.

In Bootstrap case, it included a grid, and other UI components (like a dropdown menu, and a modal dialog), but most importantly, it took care that the page worked the same in all major browsers of the time.

It helped me to prototype various projects over the years.

I have a small Nextcloud instance at home that uses BTRFS (on HDD, with noatime option) for file storage, and XFS (on SSD) for database.

I started it just for testing, and has been running for up to two years, and had no problems so far.

I would like to know if somebody has good experiences to share about AMD video cards on Linux (with the latest driver AMDGPU).

I bought a Ryzen (Zen 2) for workstation, where I need to run a few VMs, a local k8s cluster, run builds, some browsers tabs, and Slack. I have everything running smoothly on top of a Linux 5 kernel, and so far, Im pleased with the results.

But I kept an older NVIDIA card, and the drivers always had a bit of trouble with desktop Linux support (like Wayland, plymouth bootsplash, etc).

To me its a bit tricky to summarize, so its a long answer.

During the build, Gatsby compiles JSX and saves the result in a temporal folder. Some time after, it spawns several subprocesses that execute the mentioned resulting JS files (to render each page in the site).

What I meant with "the JSX code is hard to debug" is:

* The JSX code is actually run inside subprocesses, and NodeJS allows to debug a process if its run with the `--inspect` command line argument. But I did not found documentation in the Gatsby website about how to change the arguments of these subprocesses. Note that this only applies to production builds (development mode executes all JSX in the browser).

* From the text editor perspective, the breakpoints are defined in the original JSX source files, not the built ones. I understand that in theory line/column mapping can be done using map files, but I did not have time yet to investigate the cleanest way to make the IDE, Docker (not actually a Gatsby requirement), the temporal Webpack build directory, and Gatsby subprocesses to work together.

I would not recommend to use Gatsby in a project if it requires a frontend with complexity beyond static-scrollable content.

Some problems that I found after some months of integrating it with an existing CMS:

* Development complexity: depending if Gatsby is run on development or production mode, React's `render` methods are called in the browser or inside NodeJS. Having this code executed in a Node process is expected because Gatsby is a static site generator, but this big split between the environment of development and production builds, paired with a growing codebase that keeps evolving, catches new developers on our team with multiple and surprising bugs.

* Debug complexity: JSX code is hard to debug, because the code that is really executed is generated at runtime, so it is not possible for example, to put a breakpoint in a JSX file from your text editor and start a build with Node running in debug mode.

* Runtime requirements: as far as I remember, executing `gatsby build` on my development machine uses ~3.4 GiB of private RAM for the main node process, and it takes around 5 minutes if the local cache is cleared (it ends in around a minute with cache). Its important to remember this when choosing in which server the build runs.

* Integration: Gatsby does not provide out of the box integration with CMS for content authoring (like for example, page drafts).

Now to be honest, the global idea seems good (static websites built with React), but I would wait a few more years until it becomes more mature to use it again for any future project.

What does Kitura use for threading and IO in Linux?

Is there any library for cross platform asynchronus IO?

Firefox OS development as an alternative to Android AOSP would not be good for the community?

I mean, in the desktop world, we have many Linux distributions, BSD derivates, many desktop environments, etc. May Firefox OS fit some use case that Android could not?

Great article! Reading the title, I thought it was about the "tricks" that games used when the best thing available was the fixed pipeline.

I still remember how amazed I was when learned the good balance between performance cost and the resulting image when using textures for static lighting (lightmaps).

I favored Swift over Go in a small project (developed in my freetime) because it has template / metaprogramming support, and it calls destructors inmediately on unreferenced objects.

Some things that can be improved:

* It needs more support / packages for Linux (and Windows maybe?). I was using Manjaro Linux, and around November 2016 (dont remember exactly), the existing packages in the AUR didnt work anymore.

* No built-in weak collections.

* No source subfolders for the same project when using the buit-in package manager (I dont know about Go in this matter).

After chasing strange bugs when using dynamic languages like PHP and JavaScript that keep running by default when minor errors happen (PHP warnings, or undefined variables in JavaScript), I think its good that Swift priorizes safety rather than speed.

Sometime ago, i tried react and found a property named like "do_not_modify_or_you_will_be_fired" (i dont remember in which object).

I understand encapsulation is necessary, but i wonder how feels working with someone who writes code with a shotgun next to him / her.