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...
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.
Terms of service are written to be understandable by lawyers, not average end-users. At this point, understanding every terms of service, privacy policy, etc. presented by every piece of software, website, etc. encountered by an average user would require them to spend hours per week on it. This is assuming that they even have the language skills necessary to decipher the document (think of non-native English speakers, people without higher education, and so on.)
Creative Commons was on the right track with their human-readable licenses, see e.g. this example [1]. Apple is on the right track with their App Store "nutrition labels" [2]. This is what we need for people to make informed decisions. For physical objects like a Kindle, I believe such "nutrition labels" should ideally be put on the box (physical store) and website (online stores), so the consumer is aware before they go home and turn on the device (this makes it easier to compare the Kindle to a Boox or Nook at the store).
> 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.
Yes. GNOME has its bundled screenshot tool, and Zoom supports screen recording on GNOME/Wayland. Sway has grim + slurp for screenshots, and wf-recorder or wlrobs for screen recording.
However, one difference between X11 and Wayland, is that the role of the compositor (window manager) is much larger in Wayland. Thus, I believe it is up to the compositor to offer an API for features like this in Wayland, and the API may differ between compositors. In practice, GNOME has done their own thing; KDE and Sway collaborate on protocols, and are partly compatible; nearly every other compositor is based on Sway's wlroots, and should be compatible with Sway.
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.
I agree in general that too many things pop up because people want change without good reason. But Wayland is a highly needed replacement, not just in my opinion, but according to the X.org developers themselves. See e.g. this [1] talk by someone who has worked on both X.org and Wayland.
> Why would users ever not stick with something that is stable and just works?
As a user, I switched to Wayland 1.5 years ago for two reasons. The first is that Wayland has way better performance than X. It solves some long-standing and highly irritating issues with e.g. screen-tearing that I and others have been experiencing with X. The second is security. Wayland is nearly a prerequisite for proper sandboxing of GUI apps, as X apps can all keylog each other, screen-record each other, inject keys into each other, and so on, without much restrictions. Since Wayland is backwards-compatible with X via XWayland, which these days has quite good performance, I haven't yet run into an X-only app that didn't just work.
As for the issues with nVidia, that's mostly due to nVidia implementing their own Wayland backend (EGLStreams) that is different from what every other graphics card driver uses (GBM), resulting in every desktop environment (GNOME, KDE, etc.) having to implement nVidia support separately from generic Wayland support. The single biggest factor holding Wayland back at the moment is nVidia; my experience is that currently Wayland already works way better than X.org if you have an Intel or AMD card, but is highly broken on nVidia.
The second factor holding it back would be that the number of window managers (compositors) for Wayland is lower than for X, currently the main ones are GNOME, KDE, and Sway. But this is changing fast: when I first switched only GNOME worked well; now both KDE and Sway are stable and fully usable on Wayland; and thanks to wlroots, a lot of new window managers for Wayland have popped up [2] and should mature over time.
At least on Linux, Tk apps still tend to look like remnants from before Windows 95. (Which personally is the main reason I avoid Tk apps whenever possible, including Tkinter apps.)
I've known about `moreutils` for years, but the only two I ended up actively using myself are `vidir` and `vipe`.
Outside of `moreutils`, one of the utilities I always install on all my machines is `atool`, which is just so much nicer and more intuitive than trying to remember the command-line options needed to handle the various tar.*, rar, zip, 7zip, lzip, etc. archive formats from the command line.
My impression was that running 10 Electron apps would be like having 10 separate installations of Chromium running at the same time (with no shared memory). But running 10 WebView apps would be like having one browser with 10 tabs open, but where a lot of the the browser resources are shared.
In that case, I would expect a large difference in memory footprint, although both options would be bad in terms of having a non-native user interface and user experience.
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.