any1

As the author of wayvnc, I would say that I'm pretty well aware of what VNC can and cannot do. The RFB protocol (VNC) has improved over time like other protocols.

1. Wrong. There are many extensions that improve upon authentication and encryption.

2. This mostly depends on the implementation, and not necessarily the protocol and/or its extensions.

3. This would require deep integration with the window system on both sides, so I doubt that this is even a thing with RFB on Linux. There certainly aren't any wayland protocols to do this.

4. No one has ever asked me to implement any of that with the exception of audio, but there is also an extension for that.

I did a course on antennae and wave propagation as part of my university studies. The professor told us that with just a bit of extra studying we'd be able to qualify for the license, given that we already knew the engineering and physics side of things. I got the license, but never did anything with it.

That reminds me.

I worked for a company where we punched in using an iButton (it's a pretty neat 1-wire thing that fits on a key chain).

The punch clock system was logged and then at the end of the month, they printed out a single A4 sheet for every employee for us to make corrections and sign. Of course, someone had the unenviable job of going over all those and applying the corrections.

We also had to write down hours spent on different projects in a completely different system that wasn't at all integrated with the punch clock system.

At some point in the last couple of years that I worked there, they switched to Workday. That was not an improvement.

I worked for a company that went through 2 cycles like this and I can report that it had zero effect on us engineers.

My impression was that people were constantly being promoted into management and at some point we just had too many managers and that's why it was done. Of course, when you know this, the question becomes: why allow things to get to this point in the first place?

I was very disappointed when I learned that this wasn't about designing books that think.

> Fundamentally, I do not debug off git history.

Are you saying that you've never used git bisect? If that's the case, I think you're missing out.

Yes, in fact, the protocol states that the client can queue up multiple requests. The purpose of this is to fill up the gap created by the RTT. It is actually quite elegant in its simplicity.

An extension was introduced for continuous updates that allows the server to push frames without receiving requests, so this isn't universally true for all RFB (VNC) software. This is implemented in TigerVNC and noVNC to name a few.

Of course, continuous updates have the buffer-bloat problem that we're all discussing, so they also implemented fairly complex congestion control on top of the whole thing.

Effectively, they just moved the role of congestion control over to the server from the client while making things slightly more complicated.

I have some experience with pushing video frames over TCP.

It appears that the writer has jumped to conclusions at every turn and it's usually the wrong one.

The reason that the simple "poll for jpeg" method works is that polling is actually a very crude congestion control mechanism. The sender only sends the next frame when the receiver has received the last frame and asks for more. The downside of this is that network latency affects the frame rate.

The frame rate issue with the polling method can be solved by sending multiple frame requests at a time, but only as many as will fit within one RTT, so the client needs to know the minimum RTT and the sender's maximum frame rate.

The RFB (VNC) protocol does this, by the way. Well, the thing about rtt_min and frame rate isn't in the spec though.

Now, I will not go though every wrong assumption, but as for this nonsense about P-frames and I-frames: With TCP, you only need one I-frame. The rest can be all P-frames. I don't understand how they came to the conclusion that sending only I-frames over TCP might help with their latency problem. Just turn off B-frames and you should be OK.

The actual problem with the latency was that they had frames piling up in buffers between the sender and the receiver. If you're pushing video frames over TCP, you need feedback. The server needs to know how fast it can send. Otherwise, you get pile-up and a bunch of latency. That's all there is to it.

The simplest, absolutely foolproof way to do this is to use TCP's own congestion control. Spin up a thread that does two things: encodes video frames and sends them out on the socket using a blocking send/write call. Set SO_SNDBUF on that socket to a value that's proportional to your maximum latency tolerance and the rough size of your video frames.

One final bit of advice: use ffmpeg (libavcodec, libavformat, etc). It's much simpler to actually understand what you're doing with that than some convoluted gstreamer pipeline.

> It's the intended way to read/write declarations/expressions. As a consequence, asterisks ends up placed near the identifiers.

You know you don't always have to use things as they were intended?

> The confused ones will think it's a stylistic choice and won't understand any of this.

Well, I've written it both ways, and the compiler never seems to mind. :)

Maybe I should start putting space on both sides of the asterisk; seems like it would be a good way to annoy even more people.

The blog post that I linked to answers your question.

I was able to get at the diagnostics menu (also explained in the blog), but I had to interrogate a service tech in order to learn how to trigger it (also mentioned in the blog).

The manual did not contain this information and I could not find it via Google.

Where did you sign up for the "paid service with a free trial"?

I've used valgrind proactively as long as I've been programming in C and C++.

The errors that are caught by valgrind (and asan) will very often not cause immediate crashes or any kind of obvious bugs. Instead, they cause intermittent bugs that are very hard to catch otherwise. They may even be security vulnerabilities.

Another good reason for using it proactively is that small memory leaks tend to sneak in over time. They might not cause any issues and most of them aren't accumulative. However, having all those leaks in there makes it much more difficult to find big leaks when they happen because you have to sift through all the insignificant ones before you can fix the one that's causing problems.

Drawing into the spectrogram is a fun trick. I would really like to know how much data you can store in that bird using some digital modulation method such as FSK (frequency shift keying).

There could even be multiple carriers in the signal.

It would be even cooler if the bird were to preserve phase. Then you could use PSK!

I used to work for a company that makes equipment for the food processing industry.

Sometimes conveyor belts would be left running for days or even weeks in the test area. After a while, you would start to see very fine dust on and around the conveyor belts. This was finely ground POM plastic. On some occasions, there were actually heaps of that stuff forming beneath the conveyor belts.

In the factories, everything gets washed down with pressure washers at least once per day, so very little of this stuff goes into the food, but it definitely gets washed away out to sea.

I think that there is probably a wide-spread misunderstanding on how the micro-plastics enter the food. It does not seem very likely that it would come from the packaging or your tupperware (unless your tupperware is so old that it has actually started to disintegrate). It seems much likelier that the plastics were in the food before it was packaged.