servilio

The one I know about is Combobulate[1], it uses treesitter but without voice control.

[1] https://github.com/mickeynp/combobulate

I agree with you, differences in pronunciation, cadence, etc. should be taken in account as well. Though measuring those could take longer, if possible.

Spanish native here, confirming that RSA is the institution that sets the language standard.

But, people always deviate from it, though in my experience in word meanings and pronunciation, never in grammar to a degree that it become intelligible to another Spanish speaker.

The toughest film to listen to for me was "The rose seller"[1] (1998), took me like 10m to get my ear accustomed to their pronunciation.

[1] https://www.youtube.com/watch?v=ASrxQCuVT-U

don't be stupid. holy cow.

No personal attacks, please.

Personally, I wouldn't put it in certain terms like the GP has, but it is not out of the question for me.

compatibility is not an EEE tactic. embracing alone is not anything other than embracing.

where is the extending and extinguishing of Linux? name ONE thing that is possible in WSL that is not possible without it. just one.

where is the extending and extinguishing of .net? of Yammer? of Teams? where are these extensions to Linux or Android? what's been extinguished?

You are aware that EEE is in /phases/, right? Embracing is just the first one.

You people really drank the kool-aid didn't you? Think for yourselves for once.

Or maybe we just haven't forgotten history? In case you want to learn or refresh the memory:

- http://birdhouse.org/beos/byte/30-bootloader/ - https://en.wikipedia.org/wiki/Halloween_documents - https://en.wikipedia.org/wiki/United_States_v._Microsoft_Cor.... - https://www.justice.gov/atr/case/us-v-microsoft-corporation-... - https://en.wikipedia.org/wiki/ExFAT (the patent wasn't released to the OIN until 2019)

If MS wanted to kill off Linux, Linux would be long dead by now.

How do you envision they could do it? Doesn't seem plausible to me, given the distributed nature of the development of Linux.

BTW, they actually tried:

https://en.wikipedia.org/wiki/Halloween_documents

Just totally failed.

What always did, going through awesomewm, stumpwm and xmonad to now sway, was to used whatever of those services were available from the OS. Some I had to launch by hand, but that was a one time change always (some of them across WMs). Nowadays it is even easier, since most of what I needed to launch manually are now user-level service from systemd.

In the end, I am running most of the normal services a GNOME desktop would be running, but without using the GNOME shell, and that has worked very well.

It DOES have types, doesn't have type declarations, though.

Someone with enough knowledge to provide the proof would still need to be involved, but it doesn't have to be the original developer(s).

Add:

- Can't get it with subtitles/dub in _ language

The recommended way to do this now seems to be:

  (when display-graphics-p
    (global-unset-key (kbd "C-z")))

The other tool mentioned in the blog post is Structurizr, and has a self-hosted tool:

  https://structurizr.com/help/lite

  https://structurizr.com/products

They have only 110 deaths per 1M population

Where are you getting this number from? Any numbers coming from the Cuban government have to be treated as unreliable, as it is common practice to restrict doctors from what can be reported, unless they want to lose their license.

Not sure that's the reason why, not all research is done in academia. Pharmaceutical research specifically is mostly done in research centres, such as the CIGB, featured in the article, where the vaccine was developed.

Have you looked at Servo instead?

You can also use git-range-diff[1].

[1] http://git-scm.com/docs/git-range-diff

Take this code: [...] It turns out that: [...] but you've not actually said that the return value is intended, or a side effect.

Aren't the Ruby semantics clear about what happens in both of these cases (return values of methods and assignments) and hence it was the coder's choice to leave that as the return value?

Have you taken a look at buildFHSUserEnv[1]? In the Mozilla Nixpkgs overlay it is used to package[2] the Vidyo desktop application.

[1] https://nixos.org/manual/nixpkgs/stable/#sec-fhs-environment... [2] https://github.com/mozilla/nixpkgs-mozilla/blob/master/pkgs/...

RedHat announced that cockpit will be the long term successor of virt-manager

For RHEL, virt-manager will still be developed independently.

You mean this one?

https://www.nongnu.org/nomad/

There is a need for simplified workflows, but this sounds and looks like an exercise in brand marketing more than a good analysis on how to offer a better Git workflows.

Git flow forces developers to use the develop branch rather than the master. Because most tools default to using the master, there’s a significant amount of branch switching involved.

I'd like to see this fleshed out, since whatever branch naming convention or roles you use, you will be switching the same amount.

Another frustrating aspect is hotfix and release branches, which are overkill for most organizations and completely unnecessary in companies practicing continuous delivery.

Yes and no. If you don't separate master from develop, hotfix branches just work like feature branches. But if you need them separated, then...

Bug fixes/hot fix patches are cherry-picked from master

Avoid doing this, use daggy fixes[1], and it will make it breeze to check that a fix was actually merged and where[2]. And if you do cherry pick, at least use "-x".

[1] https://wiki.monotone.ca/DaggyFixes

[2] git branch --contains <commit>

Do you know if they are using the a hosted version or hosting it themselves?

Though I agree that this is not an example of EEE, it is still very similar to behaviour from the past:

https://en.wikipedia.org/wiki/Stac_Electronics#Microsoft_law...

I use Github and Gitlab on a daily basis, and participated (and still follow) in a project with an e-mail based workflows, the notmuch[1] project.

I find that the following are better in an e-mail based workflow:

- Reviewing

Threaded e-mail discussions are the best for following and/or discussing pull requests. Commits or comments no longer relevant can be hidden/collapsed to allow you to focus on what you are interested or is left to review. This is still not possible fully in either Gitlab or Github.

- Multiple versions of a pull request

Only Gitlab has support for multiple versions of a merge request. In Github there is no history of what the previous versions of the code were (or at least you cannot not explicitly compare them as in Gitlab)

- Merging into multiple branches

Though not enabled directly by an e-mail based workflow, with Gitlab/Github there is no way to ask the same set of changes to be merged into different branches in the same MR, you have to open two, and then you might issues with tools that integrate with them as they might have done the assumption that one branch is not used in two different MRs. So, even though daggy fixes[2] are possible, the norm seems to be to cherry pick.

- Custom styling

This varies with the e-mail client, but still is way better than any web interface.

[1] https://notmuchmail.org/

[2] https://wiki.monotone.ca/DaggyFixes/

  There's no xdotool support

https://github.com/ReimuNotMoe/ydotool

Also, do you know about the "i3 Migration guide"?

https://github.com/swaywm/sway/wiki/i3-Migration-Guide

True, are you aware of the following Github issue related to this?

https://github.com/NixOS/nixops/issues/565

It has links to solutions people are using, and other related issues.

Have you taken a look at NixOps[1] and Disnix[2]? They extend the concepts of Nix and NixOS into networks of machines and distributed services (TL;DR version).

If you are using only one system, the NixOS containers support might be enough, though.

[1] https://nixos.org/nixops/ [2] https://nixos.org/disnix/

Yes, the nixos-container command. That's the imperative approach, you can also do it declaratively.

https://nixos.org/nixos/manual/index.html#ch-containers

Nix, the language, is not tied to any platform. Anyone willing to make it run in a new platform, can make the appropriate pull request(s) to make it happen.

That's a very apple to oranges comparison, wouldn't you agree?

GNU autotools assists in making source code packages portable accross Unix-like systems, while make is for build automation and has fine-level dependencies (inter-files).

Nix is a package manager, and though is can build your software for you transparently, it is not tied to and specific software configurationand building toolset, can manage buildtime and runtime dependencies (including downloading the sources), caching build results transparently, etc.

Compile speed, not compiling the same dependencies all over the time.

Sounds like caching these would be a simpler but solution.

Many commercial use cases require distribution of binary libraries [...]

Good use case, and in this case another cache would solve the issue as well. Defining a protocol for binary caches and being able to add your own could solve this very well. The same solution could help solve the previous one too.

BTW, if you are in either case, have you looked into Nipxkgs[1]? They might be able to do both, the basic capabilities are there, not sure if the Rust infrastructure[2] already provides it.

[1] https://nixos.org/nixpkgs [2] https://nixos.org/nixpkgs/manual/#users-guide-to-the-rust-in...