Discord if you don't mind something proprietary, Mattermost or Rocketchat if you do, Zulip if you want something slightly different . . . and no doubt many other alternatives
Slack is easy to replace with something cheaper and better on a product or technical level. The network effects are strong of course, but they won't sustain it forever
Discord is a solid product. They just need to launch a simple business-friendly alternative UI without the teenager gamer aesthetics. I’m surprised they never tried going after the enterprise market.
Enterprise doesn't buy chat/meeting products without PSTN interop (dial-in dial-out to traditional phone line). Discord would probably need to double their dev team to add PSTN.
Building something like Slack or Teams to the level that a F500 company would make it their primary videoconferencing solution is a multi-thousand-employee project. It's not a little skunkworks project for 15-20 people in some corner of the office.
That's why TFA is hilariously flawed. When Altman says "tell us what we should build, we'll probably build it!", he's talking about driveways and backyard pools, not the Golden Gate Bridge. It's like asking mall Santa for a summer home in the Hamptons.
I know absolutely nothing about PSTN interop and I'm sure it's very complex to implement. However, at the end of the day, this is just software we're talking about right? Software is cheap and easy to produce these days and I doubt you need thousands of people to implement something that syncs your meeting's audio stream to a phone line especially given that it's a problem that has been solved before.
Hardly. You're going from analog to digital and vice-versa. You probably need specialized appliances. For every country in the world. And it's "solved" but only in proprietary contexts; I don't think there's a standard. Then you need to operate it - you need SREs, bug fixes, keeping up with downstream changes etc.
Adding PSTN to Discord is absolutely a Discord-sized problem.
Given they delete the boxes at $0, that may be cutting it close. That said they should add a flag that lets a user run down to the $0 if they want to live dangerously. They could also change it to $1 since that's their minimum balance required for refund.
I do the same with Nix as it works for macOS builds as well
It has the massive benefit of solving the lock-in problem. Your workflow is generally very short so it is easy to move to an alternative CI if (for example) Github were to jack up their prices for self hosted runners...
That said, when using it in this way I personally love Github actions
Nix is so nice that you can put almost your entire workflow into a check or package. Like your code-coverage report step(s) become a package that you build (I'm not brave enough to do this)
I run my own jenkins for personal stuff on top of nixos, all jobs run inside devenv shell, devenv handles whatever background services required (i.e. database), /nix/store is shared between workers + attic cache in local network.
Oh, and there is also nixosModule that is tested in the VM that also smoke tests the service.
First build might take some time, but all future jobs run fast. The same can be done on GHA, but on github-hosted runners you can't get shared /nix/store.
package.lock is JSON only, Nix is for the entire system, similar to a Dockerfile
Nix specifies dependencies declaritively, and more precisely, than Docker (does by default), so the resulting environment is reproducibly the same. It caches really well and doubles as a package manager.
Despite the initial learning curve, I now personally prefer Nix's declarative style to a Dockerfile
same here. though, i think bazel is better for DAGs. i wish i could use it for my personal project (in conjunction with, and bootstrapped with nix), but that's a pretty serious tooling investment that I just feel is just going to be a rabbit hole.
I think Torvalds also goes on that list as another ACME user. He mentioned as much in the extended video interview he did with Microsoft recently.
For myself, I've had to spend a lot of time without colorful syntax recently as I was working on building my own IDE and my own syntaxes and even my own system of syntax highlighting. It would have been a distraction to be constantly fighting with someone else's system of syntax highlighting while building my own! But also even having learned that I can live without it I'm hardly ready to say that I never want it back. I just want it back better. I want dynamic, contextual highlighting and I want interactive access to the underlying tree model. I want it to feel really easy to tinker with too.
None of this actually matters. If you want to keep your data private, host it on your own hardware. Countries, company policies, etc are all essentially irrelevant
Sorry if I missed this in the docs, but how robust is the persistence? ie is it the disk that comes with a standard AWS VM? or is it a share backed by e.g. Ceph with multiple redundant copies?
Details coming in the next few weeks. The contents are regularly replicated to a disk cluster, though we have some more experimentation to do before we commit to exactly how frequently. This space has a lot of trade-offs, we believe we have found a new and interesting one.
The other conclusion to draw is "Git is a fantastic choice of database for starting your package manager, almost all popular package managers began that way."
I think the conclusion is more that package definitions can still be maintained on git/GitHub but the package manager clients should probably rely on a cache/db/a more efficient intermediate layer.
Mostly to avoid downloading the whole repo/resolve deltas from the history for the few packages most applications tend to depend on. Especially in today's CI/CD World.
This is exactly the right approach. I did this for my package manager.
It relies on a git repo branch for stable. There are yaml definitions of the packages including urls to their repo, dependencies, etc. Preflight scripts. Post install checks. And the big one, the signatures for verification. No binaries, rpms, debs, ar, or zip files.
What’s actually installed lives in a small SQLite database and searching for software does a vector search on each packages yaml description.
Semver included.
This was inspired by brew/portage/dpkg for my hobby os.
yaml definitions compiled to sqlite sounds pretty similar to winget, which is scaling very well. vector search is a cool idea - how much storage does it use per package?
This is how WinGet works. It has a small SQLite db it downloads from a hosted url. The DB contains some minimal metadata and a url path to access the full metadata. This way WinGet only has to make API calls for packages it's actually interacting with. As a package manager, it has plenty of problems still, but it's a simple, elegant solution for the git as a DB issue.
I actually find that nixpkgs being a monorepo makes it even better. The code is surprisingly easy to navigate and learn if you've worked in large codebases before. The scaling issues are good problems to have, and git has gotten significantly better at handling large repos than it was a decade ago, when Facebook opted for Mercurial because git couldn't scale to their needs. If anything, it's GitHub issues and PRs that are probably showing its cracks.
For the purposes of the article, git isn't just being used as a database, it's being used as a protocol to replicate the database to the client to allow for offline operation and then keep those distributed copies in sync. And even for that purpose you can do better than git if you know what you're doing, but knowledge of databases alone isn't going to help you (let alone make your engineering more economical than relying on free git hosting).
Exactly. It's not just about the best solution to the problem, it's also heavily about the economics around it. If I wanted to create a new package manager today, I could get started by utilizing Git and existing git hosting solutions with very little effort, and effort translates to time, and time is a scarce resource. If you don't know whether your package manager will take off or not, it may not be the best use of your scarce resources to invest in a robust and optimized solution out of the gate. I wish that weren't the case, I would love to have an infinite amount of time, but wishing is not going to make it happen
Can we please stop the tone-policing, please? It's not helpful. Not everything needs Wikipedia-style citation, and this particular rhetorical trick is extremely passive-aggressive.
It doesn't seem to be their focus, but this could be amazing for macOS build machines, and servers. There have been a number of changes in recent years focussed on improving the security of macOS when used as a Desktop OS. These work well for their intended purpose, but they have made macOS harder and harder to deploy headlessly, and use as a server.
I hope to see this become an open source OS that runs the full xcode command line suite, deploys easily to headless machines, and inherits FreeBSD's server hardware compatibility.
Slack is easy to replace with something cheaper and better on a product or technical level. The network effects are strong of course, but they won't sustain it forever
reply