jabirali

> Avoiding Facebook and Google is trivial

Avoiding Google is definitely not trivial. I know here in Norway, lots of public schools are giving teachers and pupils Chromebooks, and insisting that homework is done in Google Docs. How would you propose avoiding Google in this setting? You pretty much have to bring a Google device into your home and actively use it if you want to complete your education.

Thanks for the tip! I currently don't have many tabs open, but was surprised to see every one of my work Office365 tabs (mail, calendar, etc.) at 100+ MB each...

We have very different experiences in that case.

Once I go past ~100 open tabs on Firefox, on a 16GB RAM Linux laptop, my whole system freezes. I experienced these issues as late as in June, so it doesn't appear to have been recently fixed either. Note that I do use uBlock Origin so it doesn't just buckle under from ads, but I also make heavy use of Container Tabs, which may also be a factor.

Luckily, the extension "Auto Tab Discard" solved these issues for me.

> Your own situation wouldn't be different if you had alternatives to Apple's store.

I respectfully disagree with this statement. I think an analogous situation would be the launch of Disney+: it used to be possible to watch Disney series on Netflix, but after Disney decided to launch Disney+, these series were pulled from Netflix to push the adoption of Disney+. For a Netflix user, their situation would very much be affected by Disney+ existing.

> The big problem is that almost all of the shell's are stuck in the previous century, except PowerShell.

Another exception is Nushell, which seems to be partly inspired by PowerShell, and has some very appealing ideas. However, given the time Fish needed to steal even a small market share from Bash and Zsh, it will likely take a long time before something even more radical goes mainstream. Unless of course a major player were to back this new shell, like when Microsoft pushed PowerShell and Apple pushed Zsh.

It doesn't have to be though, there's just a high correlation between hard-to-automate apps and non-command-line apps. You can e.g. make a GUI app where every button or keybinding is bound to a named function (GUI Emacs comes to mind), and where those named functions can be used in scripts. Another option is to have a scriptable backend; LibreOffice has a terminal interface that lets you e.g. convert between document formats from a shell script, and Astroid Mail is built on Notmuch as its backend which is scriptable.

Not all scientific code is amenable to unit testing. From my own experience from a PhD in condensed matter physics, the main issue was that how important equations and quantities “should” behave by themselves was often unknown or undocumented, so very often each such component could only be tested as part of a system with known properties.

You can then use unit testing for low-level infrastructure (e.g. checking that your ODE solver works as expected), but do the high-level testing via scientific validation. The first line of defense is to check that you don’t break any laws of physics, e.g. that energy and electric charge is conserved in your end results. Even small implementation mistakes can violate these.

Then you search for related existing publications of a theoretical or numerical nature, trying to reproduce their results; the more existing research your code can reproduce, the more certain you can be that it is at least consistent with known science. If this fails, you have something to guide your debugging; or if you’re very lucky, something interesting to write a paper about :).

The final validation step is of course to validate against experiments. This is not suited for debugging though, since you can’t easily say whether a mismatch is due to a software bug, experimental noise, neglected effects in the mathematical model, etc.

In some simulations, each rerun produces different results as you’re simulating random events (like lightning formation) or using a non-deterministic algorithm (like Monte Carlo sampling). Just “saving the random seed” might not be sufficient to make it deterministic either, as if you do parallelized or concurrent actions in your code (common in scientific code) the same pseudorandom numbers may be used in different orders each time you run it.

But repeating the simulation a large number of times, with different random seeds, should produce statistically similar output if the code is rigorous. So even if each simulation is not reproducible, as long as the statistical distribution of outputs is reproducible, that should be sufficient.

Fair enough :). For the record, Pandoc MarkDown supports all of these via its extended MarkDown syntax. For the first you can write [desc](src){.test} to get a class=test attribute on the link, for example. For the second, you can write {width=50%} to set the image size. For the last, tables do automatically get <th> on the first cell of each row when converted via Pandoc. This is however not standard MarkDown but Pandoc's extended version of MarkDown.

> Remember this: Markdown is all about HTML. Markdown has serious limitations and is very poorly designed in places, but it works well enough despite being so bad specifically because underneath it’s all HTML, so you can fall down to that when necessary.

Originally, this was the case, but I'd argue that modern MarkDown flavors have been separated from HTML. It's common to compile via other pathways than HTML now (e.g. MarkDown → LaTeX → PDF), and many implementations don't support inline HTML anymore (e.g. many MarkDown-based note-taking apps).

> I find that perfectly normal documents need to write raw HTML regularly, because Markdown is so terribly limited

Out of curiosity, what do you need it for? I write a lot of MarkDown, but haven't felt any need for writing raw HTML. Modern versions of MarkDown (e.g. the Pandoc variant) have native support for things like tables, LaTeX equations, syntax-highlighted code, even bibliography management.

It may be a reference to Wayland having better security than X, since any X apps can key log, screen capture, etc. each other while this is limited in Wayland.