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.

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).

[1]: https://creativecommons.org/licenses/by-nc/4.0/

[2]: https://mashable.com/article/apple-privacy-nutrition-labels-...

> 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.

[1]: https://github.com/swaywm/sway/wiki

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.

[1]: https://www.youtube.com/watch?v=RIctzAQOe44

[2]: https://github.com/swaywm/wlroots/wiki/Projects-which-use-wl...

I remember finding this video enlightening, a talk on the subject by someone who has worked on both X and Wayland:

https://www.youtube.com/watch?v=RIctzAQOe44

> I run xmonad as well, which doesn't work with wayland.

There is Waymonad, but not sure how mature it is:

https://github.com/waymonad/waymonad

You could raise the same question about many historic ligatures, like abbreviating "et" to "&" in Latin?

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.

Is this incorrect?

I'm no fan of coal, but to be fair "integrated gasification combined cycle" plants [1] are way cleaner than conventional coal plants without violating laws of thermodynamics. You can drastically reduce emissions of e.g. heavy metals, sulphur oxides, carbon monoxide, and particulate matter, while being amenable to pre-combustion carbon capture.

[1]: https://en.wikipedia.org/wiki/Integrated_gasification_combin...

> You can properly dispose or recycle anything non-radioactive with enough energy, heat and oxygen.

With "enough energy" you could recycle anything. In theory you could for instance vaporize any waste mixture (including radioactive compounds), send it through a giant mass spectrometer, and get output beams sorted by atomic number. But in practice, how much energy is "enough energy" is quite important to whether that process is realistic.

In this case, the relevant metric is how much energy is spent producing and recycling solar panels compared to the energy the solar panels are expected to produce over their lifetime. As long as that ratio can be made sufficiently low, we should be good.

> Instead you should ask if your users [...] would be sufficiently put off to look for alternatives.

This is probably sound business advice, but it's also a bit sad to shift the goal from trying to create "great software" to "not horrible enough to make all potential users run away".

When I used Emacs, Eshell was perhaps my favorite feature. I loved how modern it felt in many ways; why shouldn’t you be able to just `cd` into a remote location (TRAMP+SSH under the hood), or invoke Elisp commands like Magit straight from the shell. It could however be quite slow, and choked on some common escape codes (e.g. the progress bars emitted by the modern Ubuntu `apt` command.)

Regarding curses, I found that there was two solutions. The first is to automatically spawn curses apps in a proper terminal emulator, you just have to setup the `visual-commands` variable properly. The second alternative is to replace curses apps with Emacs apps, e.g. htop to helm-top. Personally, I ended up going the second route after a while, as I realized that there are actually very few curses apps that are important to me, and that Emacs apps are better integrated if you use Emacs for everything else.

If you rely on a lot of curses apps, a “real” terminal like emacs-libvterm may however suit you better. Renders curses apps and emojis as well as any other terminal I’ve used. It’s also much faster than ansi-term and friends at rendering.

Do you mean that you want `cmd2 <(cmd1)` as a synonym for `cmd1 | cmd2`? In that case, I’m happy it doesn’t; it drastically lowers readability compared to left-to-right command pipelines, and I don’t see what value it adds.

> They should create legislation to control access to all app stores to prevent this rent seeking

Thinking a bit wider, the same legislation should affect e.g. how Amazon can treat people who sell on their platform. They are all monopsonies:

“In economics, a monopsony is a market structure in which a single buyer substantially controls the market as the major purchaser of goods and services offered by many would-be sellers.”

> If you treat shell as a DSL for files and streams, nothing can beat it. Shell is amazing.

On the other hand, wouldn’t you just define anything that beats it also a shell? In my opinion, Fish beats Bash and Zsh in this area, and I would definitely call it a shell even though it’s not a POSIX-compatible shell. A more extreme example would be PowerShell (I’m not a fan but some people love it).

Where would you draw the line between a “shell” and an “interpreted scripting language that beats POSIX shells on dealing with files and streams”?

Firstly, your quote is about iOS not macOS as far as I can tell, so the competitor here would be Android not OpenBSD.

Secondly, I interpreted your comment as “that list is long enough to make one want to switch to Linux”. I then stand by my comment that most of the suggestions on the list require at least the same amount of work on Linux. (Source: I’m a Linux user that has setup things like fscrypt, ufw, openvpn on my devices.)

I ended up with the same muscle memory. That’s why I eventually just switched to StartPage.com instead, which is basically a Google proxy.

I went basically the same route; got rid of my Google account (GMail, Android, etc.) and switched to an iPhone. The only things left where I indirectly use Google (see below) are precisely Google search and YouTube like you.

> Then there‘s the search engine. I tried hard to replace Google Search with DDG, but I have to admit that Google gives me better search results. Still I would love to leave this also behind.

I have the same experience; I’ve tried switching multiple times, but at least for scientific topics, I find DDG far inferior to Google Search. My current workaround is to use StartPage.com, which is just a website that searches Google for you, but without letting Google track you.

> Finally there is youtube for me. Ain‘t no alternative I know about.

If you don’t need to actively publish or comment on videos, you don’t need a Google account to get most of the convenience of YouTube. Personally, I just use a good old RSS client to track my YouTube feeds in the same place I track other content (e.g. HackerNews posts). If you say that you use iDevices, I can recommend “News Explorer”, which syncs your feeds via iCloud (in contrast to all the RSS solutions that require a separate sync account).