HN user
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"?
This reminds me of my own troubles with my AEG washing machine.
Probably, the most important lesson (for someone who wants to fix their washing machine ASAP) that I learned from that was that there are non-userserviceable error codes and you need to perform an undocumented procedure on your machine to get those codes. I wrote about it in more detail here: https://andri.yngvason.is/repairing-the-washing-machine.html
I would have loved to have an open source diagnostics dongle for my AEG. Maybe next time I'll try and make one. :)
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.
This is exactly what I've done with my blog. See e.g. https://andri.yngvason.is/repairing-the-washing-machine.html
Haha, yeah, you have to hound them on the phone to get them to show up and even then they're not going to show up on time or even at all.
For the curious, this is the saga of when I had to fix my washing machine because a repair man used the wrong type of terminals when fixing it previously: https://andri.yngvason.is/repairing-the-washing-machine.html
Personally I would have bought the good drill BTW, it is expensive, but it is one of the most used tool
Yes, a good drill is a must-have for any home-owner. Anecdotally, I've owned a "prosumer grade" power drill ever since I bought my first apartment and I've used it a lot more than I originally anticipated. It's held up remarkably against a lot of use and abuse over a decade. Well, I've replaced the chuck and applied some epoxy to the plastic housing, but it still works. :)
Is it a good drill? I'd say that it's not great, but it's been good enough.
I've also bought some "consumer grade" tools and I would not recommend buying those even if you can buy it for cheaper than it costs to rent a proper tool. Sometimes, you get lucky with those tools, but most of the time, they are not worth the price of the box they come in. Often, the problem is that even though the tool doesn't exactly fall apart in your hands (this has happened to me), the precision of the result is just unworkable and you waste a bunch of time dealing with issues you otherwise wouldn't have.
Buy once, cry once. ;)
I'd happily pay for this work if I had any trust in the results.
This is exactly how I feel.
What's even worse is that when I hire contractors, I invariably have to clean up their mess and fix things myself so that they're up to my standards.
I've had a contractor do a job so poorly that it was more trouble to fix their mess than it would have been for me to do the thing myself from the start.
The initial handshake goes like this:
First TCP handshake:
- Client SYN
- Server SYN ACK
- Client ACK
- Server sends highest version that it supports
- Client sends back the version that it wants to use
- Server sends a list of authentication & encryption methods it supports
- Client chooses from the list and sends its response
- Server sends a message to the client saying auth went ok
- Client sends init message
- Server replies with its own init message
- Client sends pixel format and supported codecs and requests the first frame
- Server sends frame
- Server sends VEnCrypt version
- Client sends VEnCrypt version
- Server acks client's version and sends list of supported security subtypes
- Client chooses a subtype and sends it
- Server upgrades the connection to TLS which adds a couple of more round-trips (5 steps total for this item).
Zealotry/enthusiasm tends to float to the top and is, perhaps, what you see on the surface when you look at any community.
However, I think that most users of open source software prefer it, not because of their political beliefs, but because of their curiosity. Open source software is made by the community for the community; not to entice outsiders or sell to any would-be customers. The main draw of open source software for a curious person is that they can look inside and tinker with it and they can modify it to conform to their needs.
Saying things like "I tried your software and it doesn't work for me" or "I left it and never looked back" (usually phrased in a less polite manner) doesn't really achieve anything constructive. An open source software developer isn't interested in that kind of "feedback". After all, they're not selling anything. They're just making software for their own needs and/or to satisfy their thirst for knowledge and understanding.
If you are not curious about the inner workings of software, then open source is not for you, and that's fine.
It would need to be tested and properly integrated with x11vnc. As the goal is to move away from X11, it doesn't seem likely that they would invest time into that.
Besides, if you have x11, you can still use RealVNC.
It's based on wayvnc and noVNC with WebRTC transport instead of Web Sockets. The WebRTC transport layer has not been made public.
I once worked for a multi-national food processing automation company.
We had an internal control system based on RT_PREEMPT Linux and busybox. This system was created before buildroot and yocto became a thing. It was compatible with the company's previous control system, which ran on bare-metal 68k. I was on the team that maintained and developed this Linux based system. This all ran on hardware that was developed and manufactured in-house.
The company had also acquired many smaller companies over the years, all of which came with their own way of doing things. Most used PLC, but not always from the same vendor, some even used elaborate mechanical clockwork.
The Linux based stuff was actually pretty good for gluing all this stuff together.
At some point, a consulting company came in, and shortly after that, the management decided that the company should focus on its "core competencies". So, they hired a guy to find a replacement for all the different control systems within the company: One system to rule them all. It was to replace all the software and the hardware.
We told them, that they should rather focus on creating and documenting common interfaces; replacing everything was very clearly an impossible task. They ignored this advice, entered a contract with a single PLC company and deprecated the system that I was working on along with everything else.
A few years later, they fired that guy they hired and the CTO, but in the meantime, we all kept working on the "deprecated" systems while the replacement was "just around the corner".
Anyway, whether they were going to proceed or not didn't really matter to me. It's all about the journey, not the destination. You can keep learning whether you're doing something useful or not. You can still craft software to the best of your abilities and take pride in the art. In fact, don't think of yourself as a software engineer. Think of yourself as a software artist!
At the moment it doesn't look like flight traffic will be affected.
Yes, in fact the opposite. Air traffic controllers in Iceland were planning a strike, and they've now postponed it because of the eruption, they claim.
Source: https://www.mbl.is/frettir/innlent/2023/12/18/aflysa_verkfal...
It is most definitely closed. The only people in that area now are construction workers who are closing the gap between the two mountains Þorbjörn and Hagafell, in order to protect the power station.
Edit: For context: https://www.mbl.is/frettir/innlent/2023/12/18/i_vidbragdssto...
They're closing the barricade where the road intersects it. The northern intersection seems to be a priority rather than the southern one, like I thought first.
10 Mb/s network? Was this 20 years ago?
Admittedly, because of VNC's age, there are many sub-optimal encoding methods available and many different implementations which might not be fully compatible with each other. So, maybe your chosen server has some good encoding methods available and maybe the client can support some good encoding methods, but the intersection of supported encodings might be bad.
Users of VNC often need to understand how to tweak their settings for the best result. The client should choose the "best" encoding automatically, but this cannot be fully relied upon. On a slow network (like yours), it's probably best to select "tight" encoding, allow lossy compression (jpeg) and turn down the quality a bit.
That is to say, if the implementation that you're using doesn't support h264. Currently, there are not many that do.
On wayvnc git master and sway 1.8 (or git master), you can script things so that a "virtual" display gets created automatically when someone connects to VNC, and removed when they disconnect.
See https://github.com/any1/wayvnc/pull/200/files
The script in the PR does something a bit different, but it's only an example and can be modified to do what I described in the first paragraph.
The problem with UDP for video is that, on a lossy network, you either end up sending a lot of key frames or reinventing TCP.
There is a trick for achieving low latency video with TCP: set SO_SNDBUF to the lowest possible value and do your own buffering. If your buffer grows too large, lower the bitrate and/or drop frames.
https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rs...
I feel that the VNC protocol gets a bad reputation because of bad implementations. There's really nothing in the protocol itself that keeps it back.
What I like about VNC is that you can actually read the RFC and get fairly a good understanding of it in less than a day. I'm not sure if the same can be said for RDP.
Microsoft has this page where you can access a bunch of PDF documents that describe RDP in some sense, but I've no idea where I would even start and/or what's even relevant for any given problem that you might want to solve.