I think it's less that protobuf is a moving target, and more that gogo tried to add in all the features that google didn't want to maintain, and learned that maintaining a massive feature matrix was impossible.
GoGo was not a completely separate implementation but deeply hooked into the official GoProto implementation. So it wasn't "Protobuf the binary wire format" or "Protobuf the schema language" which changed over time here, changes to the Google's Go library caused it problems. It's like building a library that integrates with Jackson (a JSON library) and Jackson details changed in ways that added toil, versus JSON changing.
> Virt manager drives me crazy because it hides the VM files in its own directory with permissions that aren't yours forcing you to use sudo to manually manage your own fucking vm files.
I just checked my `~/.local/share/libvirt/`. It doesn't do this for me, and I don't think it ever has.
I do remember having to set this up at some point. Looks like this is it:
There are some limits around network ports in User Sessions, but it should suffice for anything you'd use Vagrant for.
> Creating a new VM? You're forced to pick an OS by typing the name of your OS into a search box which is tedious and doesnt give you an option for generic x86 machine.
...There is though? It's in the dropdown under "Generic or unknown OS. Usage is not recommended (generic)". Here it is in the code if you don't believe me:
There are two ways to run the Libvirt daemon, which are unprivileged and privileged aka system. You are using unprivileged mode, the parent is using system mode which is more powerful and provides better isolation but does hide stuff in /var.
For example, running QEMU as its own user and using PCI passthrough is only possible with the system daemon.
You also need the system daemon to set up bridged networking, though the unprivileged daemon can use it through a setuid helper.
Because if /dev/kvm isn't accessible to unprivileged users, then people will start using `sudo` to run anything involving virtualization, which would be much worse for security overall.
Linux capabilities have many problems (they are too coarse-grained and too many capabilities are root-equivalent). But anyway this is an overkill in this case probably. In may distributions access to /dev/kvm is guarded by membership in the kvm group - no need for new capability, just regular old filesystem permissions.
> /dev/kvm is guarded by membership in the kvm group - no need for new capability, just regular old filesystem permissions.
Which is precisely why many kinds of kernel feature should be exposed as operations on device nodes, not as system calls usable out of thin air. UGO and ACL permissions work on device nodes!
Would capabilities enable granting access to specific programs and not just users? Like using AppArmor profiles. So QEMU, gVisor, Docker etc. can still use KVM for unprivileged users, but malware wouldn't be able to access it directly.
That's the problem with many Linux distributions - their developers assume that you trust programs you run and if you run malware it is your fault. But you cannot trust commercial and closed-source programs so Linux is not ready for using them. Instead of solving the problem they simply make it user's responsibility.
So as a responsible user I am slowly writing my own sandboxes, struggling with lack of documentation and designing workarounds.
If you monitored all the inputs simultaneously instead of switching, you could make a low-tech radio-wavelength camera. Presumably with less SNR per "pixel" than you'd get from monitoring just one input though.
It does do directional steering. No active array components or physical movement are needed.
> If the output ports are connected to individual antennas in an antenna array, this allows shaping the beam in different directions by switching which input port the signal is sent to.
From TFA.
Presumably the geometrical shape of the lens is dictated by solving for useful phase shifts for different input points. Otherwise you could just use a bunch of delay lines.
I wonder if anybody's ever designed a 3D version of this. You might get a wider range of inputs, or more precise steering, by shaping the delays on a non-Euclidean (curved) surface (like a sphere or a saddle).
>It does do directional steering. No active array components or physical movement are needed.
By... plugging and unplugging antenna elements?
It makes a fixed directional antenna element array which is configurable to a small degree by choosing which antenna elements to connect and their spatial arrangement.
The radiation pattern can only change by physically plugging or moving antenna elements.
No. The antenna elements are always plugged in the same way. By sampling/introducing the signal at a different physical position on the lens (or multiple positions simultaneously), you create different physical distances and phase shifts for each element, and therefore a different beam direction.
...Apropos of nothing, this reminds me that a long ago, I played on a Minecraft server where one of the boys made a piston display with controlled by a pressure plate array. I was shocked by how he managed to transmit the signal with a simple wire. Maybe it was a similar idea, using the propagation distance...
>By sampling/introducing the signal at a different physical position on the lens
Which is accomplished with active components (or multiple frontends). The word "active" is carrying a lot of weight in what isn't actually that important of a distinction
Additionally the developer of this library is active in the indie game scene, so "twelfth member of the team" is hardly a relevant issue.
I find it so unfortunate how many of the criticisms raised here are mooted by simply glancing at the README.
There's an interesting conversation that could be had about the needs and limitations for debug UIs, and how to balance that with minimal code. (E.G. Would feeding this library's text-and-rectangles output into an accessible renderer be enough?) But blanket rejections and reflexive judgement aren't helpful.
> Any project that uses Dear Imgui for end-user applications has already made a bad design choice.
Note that any project using Dear ImGui will presumably have read the README for it, the second paragraph of which starts:
> Dear ImGui is designed to enable fast iterations and to empower programmers to create content creation tools and visualization / debug tools (as opposed to UI for the average end-user).
> I guess a lot of folks consider games exclusively for folks without those accessibility needs, so maybe that's why something like Dear ImGui can live for years in thousands of projects without anyone complaining about accessibility. But, I wouldn't consider it for anything that isn't specifically about graphics and I don't think anyone else should either. (No one has to listen to me, but I think less of them.)
Immediate mode UIs are mostly for debug menus, not even gameplay/graphics. It doesn't need to be accessible to anyone except for the developer(s) choosing the library and making the game. (If the developer has different needs, obviously they can choose another library, unlike users who must live with the developer's choice.) The fourth sentence in the linked ImGUI repository explains this intention very clearly.
You can spend all this energy imagining malice and thinking less of others, but doing so does not add merit to your critique. Nor does it advance the cause of software accessibility.
But, in my defense, I did say "software that could be useful to folks with accessibility needs that don't try to address it (within bounds of their resources and capabilities, obviously lots of OSS just doesn't have the ability to deliver an accessible experience for tiny little throwaway apps)". If that aint you and that aint the software you're making, I'm not talking to you. And, sometimes accessibility isn't just for blind users.
reply