Professional tech writer here: We use GitHub and a tool called OxygenXML to write docs-as-code in an XML DTD called "DITA". It's a hefty IBM invention from the early aughts, but it covers every use case I've thrown at it, from small documentation sets to multi-thousand-page monsters. Supports PDF, HTML, Word, and many other output types.

DITA's so great at everything _except contributions from non-tech writers_ that half of my career has involved migrating tech writing stacks that use it to Markdown/SSGs in git repos.

DITA's benefits require a certain scale that most tech companies never achieve. And the Open Toolkit is a nightmare piece of software.

Agreed, and we use Markdown where we can. But inevitably some product manager comes along and demands tables inside tables or embedded reuse of content... and it's back to DITA.

OxygenXML makes the OT much more manageable. I haven't had to touch an OT XSL transform in a few years now. Worth every penny.

> The problem is, there are very few tutorials showing you the current best practices.

As someone looking to expand from simple Python scripts to serious Python projects, this is my primary issue. Do you have any recommendations?

I like to brag and say the best blog I know about Python is mine. But it's in french so you will have to take my word for it. Yet it has more than 300 articles about Python and covering at length stuff from decorators to metaclass and even a fat 8 parts manual on OOP. Maybe google translate can help.

linky?

Thanks

Edit: NSFW!

Given how regularly Western Bitcoin exchanges are hacked, I'm not convinced anyone has the knowledge to securely manage a Bitcoin attack.

Atom packages debs in their GitHub repo which work in Debian 8. There's no repo you can add to your sources that I am aware of, but you can manually download the deb from https://github.com/atom/atom/releases/tag/v1.11.0, run dpkg --install filename.deb, and get coding.

Give it time. Once systemd runs out of Unix utilities to consume, it will inevitably turn on WinInit.exe and the Service Control Manager.

Original size: A mere 4.3 GB.

> Now, looking at a device like this, I automatically compare it to something like a tractor or plow. It demands constant connectivity to Google HQ... it's full of secret code... it requires, for its basic paradigm, a private company's acquisition of staggering amounts of surveillance... and so on.

As someone who used to write code for snowplows, they're also becoming quite centralized. Location, plow settings, salt per mile/km usage and other values are tracked in real time from the municipal office. Municipalities are increasingly strapped for cash, so performing real-time data analysis on their services can save them quite a bit of money in the long run.

Those responsible for auditing the auditors who have just been audited, have been audited.

Welcome to the "many eyes, shallow bugs" side of the world.

Which is why the linux kernel is such a pinnacle of security excellence. /s

As is standard for a Phoronix.com "article".

I wondered how the author had written "more than 10,000 articles".

Ha, still not as bad as their "benchmarks" though.

What's bad about his benchmarks? I've cursory glanced at them before and didn't notice anything in particular (used to write gpu drivers for a living).

As long as the people submitting those pull requests understood the ramifications of contributing code gratis to a proprietary platform, there's nothing sad about it.

you probably sign a license agreement: there's no "As long as you understand"

Yes, to gain access to the GitHub repo you need to sign up for an Unreal Engine license which involves accepting this eula:

https://www.unrealengine.com/eula

Correct. I think people do this when they need new features/fixes now. In some cases you gain the future benefit of the maintainers being more open to your issues/feature requests.