To my knowledge, there isn't a single definition of a union. In America, it seems to mean something wildly different than what I'm used to in my part of Europe.
To me, it is simply an organization by workers to collectively bargain with capital (who have their own equivalent to unions). The unions also typically offer unemployment insurance as well as income replacement in case of strikes, which are a possible measure that can be organized by the unions to force capital to come to the negotiation table. An employer has no right to know if you're in a union or not, so it would be quite impractical to try to hire only non-union members, and most companies don't mind either way, because the collective bargain agreements go both ways and can make it simpler than negotiating individual agreements with each employee.
In the US, it seems like unions are what I would call a guild - very highly coupled to a particular profession. Where I'm from they typically accept anyone who works in a general sector (say medical, government, transportation, etc.), as typically most workers in the same sector would have similar challenges and goals.
I did the same, except I'm paying for Mullvad through the Tailscale partnership, so I reached out to them and expressed my desire for them to partner with other privacy focused VPN providers like Njalla, Airvpn and others. I don't feel great about my money funding ethno-fascists in my country.
Firecracker launches small, but otherwise general purpose virtual machines. Containers, at least the standard implementations that most of us use, use kernel features like namespaces to isolate workloads, but still share a kernel so the sandboxing is not as strong.
Wasm is a virtual machine, just like for example the jvm is, that is designed around only allowing the executed program access to the host runtime via specific apis that are subject to security policies. It does not run arbitrary software, but rather only software built to target specifically wasm.
The software this post is about is just bundling a wasm runtime with other software for convenience.
Anyone have ideas about what to do when using cgroup weights rather than max?
I'm currently in the process of removing cpu.max from our clusters, to allow applications to better utilize the available cpu time which currently is just being wasted. We will use cpu weights to make sure that cpu time is fairly allocated during contention, and to not oversubscribe the hosts, but I'm sure that among the thousands of applications that are running on those clusters today, many will be relying on cpu.max to size threadpools etc.
On the one hand, we do want applications to use the available cpu time, but at the same time they need to not kill themselves by running out of memory.
Network policies controlling egress would be one thing. I haven't seen how you make secrets available to the agent, but I would imagine you would need to proxy calls through a mitm proxy to replace tokens with real secrets, or some other way to make sure the agent cannot access the secrets themselves. Specifically for an agent that works with code, I could imagine being able to run docker-in-docker will probably be requested at some point, which means you'll need gvisor or something.
The next release includes a way to use a command palette to search for and jump between surfaces (windows, panes), which sounds like it partially addresses your third point. I had a small hand in it, by building the initial UI for the Linux version.
There's zero percent chance that I would proxy all my LLM calls with my API key through some third party service. However, if it was self-hostable, so that I can ensure it is only able to reach the LLM providers, I could see deploying this behind an LLM provider router. If it actually achieves the kind of token use reduction that is advertised, that would be worth paying for - especially in the enterprise. I'm skeptical of using it for product integrations, where prompts are tuned for effectiveness and efficiency, but for ad-hoc usage it probably doesn't matter too much if the phrasing affects the results a bit.
How does it deal with partial failures like the upstream being unreachable from one datacenter but not the other, or from one region but not another? Or when the upstream uses anycast or some other way to route to different origins depending on where the caller is?
Making your circuit breaker state global seems like it would just exacerbate the problem. Failures are often partial in the real world.
You can find the forks by looking in the "network" part of the UI.
I do agree that GitHub could do more to highlight forks and their relationship to one another. But I don't think the current way - having an open pull request - is the only way to do that.
As a former maintainer, I am very in favor of this move. After having spent 10 years or so being hounded with "Any update on this?" and "Can we get this merged?", I don't think I would ever do it again as long as there aren't controls in place to be able to set the expectation that the code is free to do with as you will, and please go ahead and fork if you want it to do something different.
Cool! While in Kubernetes you have cilium that does basically the same thing, outside of Kubernetes I've been using explicit proxies to do this kind of thing, which requires applications to support http proxy. I could definitely see transitioning those workloads to using ebpf filters instead.
Any fundamental reason you can't allow/block individual ports, or just a design choice?
That is correct. The emulator is implemented in JavaScript using OOP, and the tests that the game runs to validate your progress has certain expectations on what you export and what methods are available.
Been a Kagi subscriber for a while, and am supportive of a more diverse browser ecosystem. However, I won't be using this browser as long as it is closed source. Honestly, the arguments made by the founder (I believe he's the founder anyway. I may be wrong) in the related feedback thread kind of soured me a little bit on Kagi. The arguments were essentially:
1. It's a lot of work to maintain an open source project accepting community contributions. Absolutely true, but that's not what's being asked for. Providing a tarball under an open source license doesn't add any significant work.
2. No one has asked for the Kagi backends to be open sourced, so why is the browser different? Obviously because I run the browser on my machine. Your backend runs on your machine.
3. We need to protect our IP. Then release it under a copyleft license. Or if you absolutely must, release your proprietary bit under a non-open source license.
4. You don't need the source because we send 0 telemetry, which you can verify using a network proxy. That's hardly the only thing to be worried about with a binary blob. Even if you kept the code completely closed source, by just releasing a tarball with the source under a proprietary license, I can build my own binary from source and eliminate this threat.
I'm sure part of it is so that marketing can say that their TV has new putz-tech smooth vibes AI 2.0, but honestly I also see this same thing happen with products aimed at technical people who would benefit from actually knowing what a particular feature or setting really is. Even in my own work on tools aimed at developers, non-technical stakeholders push really hard to dumb down and hide what things really are, believing that makes the tools easier to use, when really it just makes it more confusing for the users.
I have almost the same experience. I'm not running my own ISP and I'm not in a country known for originating DDoS attacks (Sweden), yet just using Firefox on Linux seems to be enough to be forced to click on traffic lights many times an hour. If I'm using Mullvad VPN that accelerates to almost every minute. CloudFlare claims to support privacy pass, but their extension implementing it seems to do absolutely nothing.
That link doesn't answer the question though. It states that the extension is reviewed before receiving the recommended status. It does not state that updates are reviewed.
Not stated in the most diplomatic way, but I do agree. Having used CDK (not cdktf) and now being forced back to Terraform feels like going back to the stone age. It is absolutely obvious to me that generating infrastructure definitions from a regular, testable language using all the same tools, techniques and distribution mechanisms that you use for all your other software development is the superior way. Being able to piggyback off of the vast ecosystem of Terraform providers was a really clever move, although I understand it led to some rough edges.
I suppose that's true, but it makes it quite hard to communicate specific concepts if everyone gets to come up with their own definition of existing terms. I'm aware that language evolves, but at least at the moment, expecting projects to be community driven just because they use the term open source when describing themselves will set you up for conflict if they are referring to the conventional definition of the term and don't also happen to want to run a community driven project.
Completely disagree. To me, and the OSI, none of those things other than redistribution and forking have anything to do with being open source or not. In fact, you could have a closed source project tick nearly all of those boxes, although that would indeed be very unusual.
I'm not sure if there is a term for what you are describing. Perhaps "community driven project".
Do we work in the same company? That said, I really don't understand why everyone hates on Bitbucket. I really thought it was _fine_ from a user perspective. Now we're on GHE and I find it a sidegrade at best.
Now for the people who were operating Bitbucket, I'm sure it's a relief.
To me, it is simply an organization by workers to collectively bargain with capital (who have their own equivalent to unions). The unions also typically offer unemployment insurance as well as income replacement in case of strikes, which are a possible measure that can be organized by the unions to force capital to come to the negotiation table. An employer has no right to know if you're in a union or not, so it would be quite impractical to try to hire only non-union members, and most companies don't mind either way, because the collective bargain agreements go both ways and can make it simpler than negotiating individual agreements with each employee.
In the US, it seems like unions are what I would call a guild - very highly coupled to a particular profession. Where I'm from they typically accept anyone who works in a general sector (say medical, government, transportation, etc.), as typically most workers in the same sector would have similar challenges and goals.