I do pair programming very frequently with my coworkers remotely. We share a VNC connection to a Linux host. It works great.
415 karma · joined February 14, 2018
I do pair programming very frequently with my coworkers remotely. We share a VNC connection to a Linux host. It works great.
Live visualization takes a live music performance as input and programmatically generates a video that matches said music performance. The video might pulse along with the beat of the music. Or maybe it changes color or shape depending on the “mood” of the audio. The computer driving the visualization receives audio from the live music via a line in, which Apple treats as an active microphone.
A simple live visualization would be to display a video showing the waveform of the live audio feed.
edit: looking at your updated post, it is called a "playback card."
That is an uncommon acronym.
Other niches are history videos and music analysis videos, the former which gets demonetized and the latter receives copyright strikes with abandon.
Many history channels are on Armchair History TV: https://armchairhistory.tv/content-creators/
Adam Neely (music analysis) is on Nebula: https://nebula.app/
> It is called Poe's law, and Google returned it at #4. Bing or Duckduckgo don't have a clue...
Interesting, I was looking for a good benchmark like this. For me Google returned it at #5 with an image/related terms carousel before it which places it physically more around #7 on the page. Brave Search (never tried it before today) puts Poe's Law at #8. So Google is still better.
But the other results are mostly worse (IMO) on Google. Here are the first 8 results:
- 175 Bad Jokes That You Can't Help But Laugh At - Reader's (rd.com)
- 57 Hilarious, Silly Jokes No One Is Too Old to Laugh At (bestlifeonline.com)
- 145 Best Dad Jokes That Will Have the Whole Family Laughing (countryliving.com)
- Sarcasm, Self-Deprecation, and Inside Jokes: A User's Guide (hbr.org)
- Poe's law - Wikipedia (wikipedia.org)
- Managing Conflict with Humor - HelpGuide.org (helpguide.org)
- 175 Bad Jokes That Are So Cringeworthy, You Can't ... - Parade (parade.com)
- Encouraging Your Child's Sense of Humor (for Parents) - Kids ... (kidshealth.org)
And here are the first 8 results from Brave Search:
- phrase requests - Is there a word for "pretending to joke when ... (english.stackexchange.com)
- Joke - Wikipedia (wikipedia.org)
- “Are you joking or serious?” – The Caffeinated Autistic (thecaffeinatedautistic.wordpress.com)
- How do I tell when people are joking or being serious? (reddit.com/r/socialskills)
- be a joke | meaning of be a joke in Longman Dictionary of (ldoceonline.com)
- Quote by Ricky Gervais: “If you can't joke about the most (goodreads.com)
- How can you tell if someone is joking with you or not? (quora.com)
- Poe's law - Wikipedia (wikipedia.org)
-----
edit: I did not count to 8 correctly the first time. Fixed that.
No, I do not give a single fuck about Nix versus Docker. I have no personal attachment to either. I am just worried that pushing Nix at my company would be some form of professional malpractice given the downsides. I literally have a meeting tomorrow about incorporating Docker into a different team's product. I've used both Docker and Nix before. If Nix would be better for them, I would tell them as much. I'd be fine continuing this discussion we are having, some parts were interesting. But unfortunately you seem incapable of formulating an argument without resorting to personal attacks and condescension. And I cannot tolerate that.
Any results should be documented by making all data and code available in such a way that the computations can be executed again with identical results.
https://en.wikipedia.org/wiki/Reproducibility
-----
> To be clear, are you suggesting that > RUN sudo apt-get update && sudo apt-get -y install ...
No, you need to pin the dependency versions. With Python this practice is already normalized with requirements.txt or conda yml files. So you would take an existing project and do:
RUN conda env create -f environment.yml
which would likely be copy-pasted from the project README. The yml file specifies version numbers for dependencies. The SAT solver is deterministic. For other languages like C maybe the project didn't specify dependency version. So you need to figure them out when you first get a successful build, then specify their versions in apt. You can specify version numbers in the apt-get install line.Yes, this is reproducible. Definitely good enough for most business use cases. When I say reproducible I do not mean ivory tower math proof reproducible. I just mean that the code will run on the relevant machines they are targeting. As I wrote in my initial comment. And as I defined at the top of this comment.
Also Nix provides a worse experience for pinning dependency versions since it does not have a native concept of version numbers [0]. Instead people have to grep through the Nixpkgs repo to find the correct hash of their dependency version.
> This is even more true for Nix, which has the largest and most up-to-date package repositories out there
No, Docker has the closure (to borrow Nix's terminology) of all of the package managers in that graph. If you add the height of the Debian packages with Pypi and Hackage you already have Nix beat. You can keep adding - cargo, ruby gems, etc all in their native package managers. If Nix were better off then people would be adapting Nix packages to other ecosystems. But the reality is the other way around.
> Plus, with Nix, you can easily make a new package based on existing packages with a mere few lines of code if the existing packages doesn't fit your needs. Other package managers besides Guix doesn't offer you that flexibility so you'd have to compile from scratch
With Nix, you are forced to make new packages based on existing packages. That is not a benefit. Regarding "if the existing packages doesn't fit your needs", compiling from source is not a big deal since Docker caches output artifacts.
They fulfill similar business functions - allowing you to run the same code on a bunch of dev machines and on prod (modulo modifications for e.g. database storage in Docker's case). Nix people get hung up on the fact that Docker runs containers, but it doesn't really matter that much. Often Docker is the shortest path to getting software running on multiple machines reproducibly.
> I also don't understand what you mean by "bindings"
I am referring to derivations and modules. Both are glue that you have to write for existing software that is already packaged. With Docker you leverage the existing packaging ecosystem like pip or apt. The packages are already written for you, and you can follow the installation instructions from a project repository and they translate seamlessly into Docker.
For example with ML & Python - If you want PyTorch with CUDA support, you can follow the official documentation [0] and basically copy and paste the installation instructions to a Dockerfile RUN statements. If anything breaks you can file an issue on the PyTorch issue tracker which has a wide audience. With Nix you have to write glue on top of the installation yourself, or a maintainer does it with a much smaller code review and support audience. Sometimes the audience is just the author, given that Nix project people commit directly to master frequently and do self-merges of PRs [1]. And there are other hurdles like compiling Python C extensions, which are pervasive.
Another example is with software systems, I guess this would be a Nix module. Here's GitLab: [2] where it was really difficult to translate the services into Nix. But a lot of company internal services can look like GitLab with a mix-mash of odd dependencies and languages. And writing a Dockerfile for this is much easier than Nix, since you can copy from the existing README specifying the Debian or language-specific dependencies. (edit: and if there are conflicts between dependencies of the services they can go into different containers. Getting the benefit of Nix - reproducibility - without the extra effort.)
[0]: https://pytorch.org/get-started/locally/
[1]: https://discourse.nixos.org/t/proposal-require-pr-authors-to...
It was frustrating reading all the official intro documentation on Nix and it only talking about nix-env (not declarative AFAIK) or how to use Nix for per-project dependencies.
No one in the comment chain claimed otherwise. Breaking changes every rand() * (6 months) is not much better than breaking changes every 1 * (6 months). It still means you have to validate your firewall configs once or twice a year and randomly need to push these changes to network appliances with the same cadence. A key benefit of application stability is not having to constantly read release notes and check if your use case is affected by the changes.
> You have six months to make mostly minor changes to pf.conf before you are out of support. They release every six months and patch the last release.
Yes, they have a schedule for rolling out breaking changes. This is a maintenance burden.
> The changes aren't made for the heck of it, they make a more consistent system overall with new knowledge.
The same is true of many breaking changes in applications and APIs broadly. A cleanly designed system does not magically make the ensuing maintenance burden disappear. We probably all agree that OpenBSD and pf are well designed but we should not ignore its costs.
This just links to a manifest.json
OpenBSD implemented the ASLR security mitigation as default in their operating systems first. Windows and macOS followed years later. I don’t think they did so because of OpenBSD’s market share.
https://en.m.wikipedia.org/wiki/Address_space_layout_randomi...
What does this mean?
[0]: https://www.bbb.org/us/tx/dallas/profile/bus-lines/greyhound...
Some figures:
- 10 percent of Pittsburgh residents commute by walking [0]. 17 percent commute by public transit [1].
- "According to the U.S. Census Bureau, public transportation commuters in Pittsburgh spend an average of 32 minutes traveling to work, the 11th-fastest transit commute time of the 136 cities in our analysis. That is also just nine minutes slower that the average commute time for drivers, the fifth-smallest difference." [2]
[0]: https://en.wikipedia.org/wiki/List_of_U.S._cities_with_most_... [1]: https://en.wikipedia.org/wiki/List_of_U.S._cities_with_high_... [2]: https://smartasset.com/mortgage/best-cities-for-public-trans...
edit: formatting
If this were the primary factor, the top cities for cycling would be places with mild climates and active-oriented population. That is not the reality as I see it.
> No doubt some combination of all these factors are at play
The primary factor is unambiguously the infrastructure. Among top cycling cities, the only common trait is good bike infrastructure.
> presuming that a materially greater portion of the population would start biking if we could only solve this one aspect of law or gear
No presumption needed, that is what literally happened in the Netherlands. They created good infrastructure, and went from basically zero cyclists in the 70s to the hefty majority they have today. The top cities for cycling (by ridership) in Europe are in northern climes with good cycling infrastructure. People in these cities are exposed to cold rain and snow.
see: https://copenhagenizeindex.eu/ , no correlation between climate and ridership.
Speaking to your broader point that people are getting lazier - I believe that humans are exceedingly adaptable above all else. If it is fast and convenient to get from A to B in a city by bike, people will ride bikes. That is what happened in the Netherlands and other top cycling cities.
> ER costs are also a problem, but it’s an orthogonal issue.
It's natural to want to discuss this orthogonal issue, and the solutions to the two issues are not mutually exclusive.