Does multicast actually work from a home network to another set of homes over the internet? I thought this traffic would just get dropped by one of the hops along the way if you tried it.
I think it never took off and is not supported by many if not most routers.
However, it is an efficient solution for sending live-stream data over the web. I think eventually the pressure to not send packets for each consumer but at most once per port will take over and force providers to implement this or a better solution.
Like Rust, F# doesn't have higher-kinded types so it's not generalized like GP is proposing. Each type of computation expression is tied to a specific monad/applicative.
I used to think there's nothing wrong with them either. For simple setups it is very painless. However, I recently stumbled into a use case where setting up the project file is a huge hassle and very error prone as well.
Mainly I wanted another project to be referenced only at the "analyzer" step, and this appeared to work just fine at first, but after the 3rd/4th compilation it failed for some reason. Digging into this opened a huge can of worms of partially/falsely documented features for something I sincerely believed should be easy to achieve. Now the only thing I can do is copy the project into the analyzer, or let the build fail with the dependency disabled just so that the next build works again.
There's also some issues regarding restoring other projects, but that doesn't appear to be the fault of .csproject files.
P.S.: Having a project be referenced (i.e.: marker attributes) at both the analyzer step _and_ later in the final artifact is something I never got working reliably so far. From what I've read a nuget project could make this easier, but I don't want to do that and would expect there to be a way without using the package-management system.
> I used to think there's nothing wrong with them either.
From your complain, it doesn't seem you're pointing anything wrong with .csproj files. You struggled with a usecases that's far from normal and might not even be right for you. Without details, it's hard to tell if you're missing something or you're blaming the tool instead of focusing on getting things to work.
I found a solution I am happy with. Based on my research into this it is a problem I'm not alone with.
I do concede that writing your own analyzers is unusual (which is why i wrote that it's fine for simple setups).
At the same time I deem having a common library to be referred by more than one analyzer project something that should be possible without running into strange errors.
If a tool (dotnet build) tells me something is wrong I am fine with it. If the same tool works after I added something to the project description and then fails at a random time after without having changed the referenced stuff, then I will happily blame the tool.
Especially when commenting out the reference, recompiling until error, and then uncommenting it fixes the issue. While this behavior doesn't necessitate an issue with the files per-se, there is only entity consuming it, so to me there is no distinction.
if you pick a value you have to store it, and if you have to store it it might spill into memory when register allocation fails.
Moving from register-only to stack/heap usage easily slows down your program by an order of magnitude or two. If this is in a hot path, which I'd argue it is since using uninitialized values seems senseless otherwise, it might have a big impact.
The only way to really know is to test this. Compilers and their optimizations depend on a lot of things. Even the order and layout of instructions can matter due to the instruction cache. You can always go and make the guarantee later on, but undoing it would be impossible.
Ignoring the comment you replied to, I am curious about the claim that pipewire is incompatible with the audio card.
I get that pulseaudio cannot default to using an output with speakers. This happened to me too on every single login, so I switched to pipewire, which is capable of saving settings between seessions (pulseaudio claims to support this, but it's been broken for over 10 years based on my internet searches).
I guess I got lucky that pipewire can talk to my card?
I'd expect it to be far enough up the stack where hardware compatibility wouldn't matter.
I distinctly remember having to install a package before audio would work on my machine. Needless to say, that isn't the best option if you can't rely on your eyes to find out what's missing.
Unfortunately, I'm not knowledgeable enough about how audio is done in interaction with hardware to help satisfy your curiosity.
As far as I know tacking on security after the fact usually leads to issues.
It should be a primary concern from the beginning. Even if you don't do it 100% right, you'd be surprised how many issues you can avoid by thinking about this during (and not after) development.
Dropping your rights to open files as soon as possible, for example, or thinking about what information would be available to an attacker should they get RCE on the process.
Shoehorning in solutions to these things after the fact tends to be so difficult that it's a rare sight.
I have been recommended to think of security as a process rather than an achievable state and have become quite fond of that perspective.
Funny enough, I believe that there are quite a lot of tutorials and that itself is the issue. Everyone wants to make their own since they deem the others to be bad and then a new subpar tutorial is created, making it even more difficult to find the few helpful articles. This ends up becoming a vicious cycle.
In the end I find comparing vim to something like snowboarding or skateboarding intriguing. It doesn't matter how much you explain it, it won't be enough. You just have to try it out for yourself and see if you can get the hang of it. Once that initial step is done, that's when reading about all the intricacies becomes useful.
reply