755 karma · joined May 16, 2021
[1]https://tomorrowcorporation.com/posts/how-we-make-games-at-t...
Now we are in the same position as a hundred years ago. At that time you would have to go into a theatre by the production company and now you have to go to the streaming service of the production company.
That split between production and distribution has to come back.
This screams modular system at me. And I think it is much easier to learn what all of these functions do when combining multiple senses.
Of course the state spies on you. After Edward Snowden everyone should know that. And thats a big problem because the state is the one actor that should fight to protect you from surveillance. But let's not claim that big tech is not the motor of the machine that is state sanctioned surveillance. Google allowed the US to read your e-mails. A yahoo software was responsible to access your webcam from the outside. NSO sold Pegasus to state actors.
That sounds bad enough. But if these companies would care about their users they would stop this from happening. Right? Of course these companies will tell you that they need your information to provide you with the best service. In reality they want to collect the biggest value as possible from you.
In the past you would just pay for a service and the service would provide a service. If the company wanted to extract more value from their users they would raise the prices. But today is different. It is no longer just a transaction between you and a company. It is also a transaction between the company and a third actor who is interested on spying on you.
The motivation changes. It is no longer about protecting you country or whatever. It is about money. And companies want to make money. And if companies see a legal opportunity to make more money they will take it. They will sell as much of your data as possible.
Now you will tell me that I should just stop using these services. But that's not so easy. Network effects are real. If they aren't real for you? Great. But other people have friends outside of tech circles. Now if you want to have a social life you need WhatsApp or other services. This is an even bigger problem in developing countries that are literally dependent on these "free" services.
Normal people wont buy a homeserver, self host a matrix instance and convert literally everyone in their friend group to element. They will go for the cheaper solution and just download WhatsApp. But they don't know that they are paying for this service with their data. E2EE? Yeah right, your Messages can only be read by me, you and Facebook.
This is why we are in dire need of anchoring privacy into law. People will go for the cheaper option. But if you are in need of using a service it should not come with strings attached. And if your service is only sustainable by selling the private correspondence of people it deserves to die. There is plenty of great OSS that just doesn't have the network effects of proprietary ones.
That said, during competitions it is not allowed to use external motion tracking as it is used in the paper. The necessary image processing takes a good chunk out of the processing power budget and the quality of image sensors this size doesn't help. Also most teams wouldn't train their expensive robots this way because the risk of damaging it is way too high.
I think this is a glimpse of what's to come in robot soccer. But we are a long way away for self contained autonomous robots to behave this way.
As for alternatives there really is not much to choose from. For small projects which are not reliant on the performance/native designs of Qt, Dear ImGui looks nice[1]. But it is very much tailored for a different Use Case.
Edit: I said that [0] is a nice website. But you only get a complete view of the situation if you cycle through all of the open source licenses. Too bad there is no "Open Source" option. Would hurt their sales I guess...
You even require written permission from Qt to upgrade from LGPL to the Commercial License[0]. Because if you started programming without paying them their fees you probably owe them even more money according to them...
[0] https://www.qt.io/faq/tag/qt-commercial-licensing (If I have started development of a project using the open source version (LGPL), can I later purchase a commercial version of Qt and move my code under that license?)
If car manufacturers would decide to support upgrading the Qt version by uploading shared objects directly to the car there would be no need for them to buy Qt Licenses. Because technically they could support all points of the LGPL. But that will never happen for two reasons:
1) It is very hard to get out of the contract if you already bought a license. You would have to prove that you aren't using any commercial tools anymore (of course they are the same tools as GPL but installed a different way).
2) They are car manufacturers and known to lock down their systems as much as possible.
The Qt Company probably didn't think about the average C++ Developer or Desktop programs at all while writing these Terms and Conditions...
Everyone who is saying that Qt is too expensive -> It's free. Just Use LGPL. All the tools are GPL but that doesn't matter if you don't want to link against those. The Libraries itself are LGPL so you can dynamically link against them with attribution.
Everyone who is saying that they need the Qt Support -> You probably don't. If you live on the bleeding edge you sometimes get cut. Qt for all its flaws really is fine. And if you get stuck the community will help out just as good.
Everyone who is saying that they already bought into it -> Bad news for you. The license terms of the commercial license are very restrictive. If you are building an application which communicates over a network or building a system which consists of multiple programs you have to make sure you don't integrate or communicate with a program which uses the LGPL variant[0]. Yes that's right, if you pay them money you better make sure that you never run your program on KDE because it would inadvertently communicate with software that you are not allowed to communicate with. Of course you are allowed to communicate with everyone while using the LGPL.
ALWAYS use the LGPL variant! Unless you are not able to work within the boundaries of it.
If you have to spend money you are better off donating to the KDE Free Qt Foundation.
[0]https://embeddeduse.com/2023/01/06/using-qt-5-15-and-qt-6-un...
It sure might be a dystopian hellhole. But at least some shareholders got rich.
What's the point of E2EE if you can't be sure that the decrypting app isn't sending your data elsewhere?
On the other hand, if you answer yes to this question they will probably don't let you into the country... But I can't say for sure.
This seems crazy to me. How could you ever enforce this? If I buy some Software which uses the Qt Commercial Variant internally, you would have to make sure that it doesn’t support any standard IPC Protocol, that a potential LGPL Qt program could use too.
The default answer to the question if you should use LGPL or commercial should always be LGPL. Unless you really really have to use Qt on an embedded system. Otherwise the Qt Company will come for you…
Edit: One of the bigger Problems with Qt6 is, that there are no more non-commercial LTS Versions. This forces some bigger companies to buy out of fear and/or policy. Even if they don’t build embedded systems. And if you bought in once it is very hard to get back to the LGPL variant.
Does consent even mean anything if all Ad companies have legitimate interest to track you?
It is true, that estimates of states will drift off the ground truth very fast, but I don't think that ML approaches are the best solution to these kind of problem. In our tests we tried to estimate the position of a bicycle solely with an iPhone taped to the handlebar. My first idea was to update the state based on the fact, that the handlebar would always point in the riding direction. And the second idea was to update the altitude of the estimation based on a heightmap of the environment.
Of course, without these two approaches the estimation would drift off rapidly. But the first approach was enough to confine our estimation to the general area of riding (at least for the time of measuring). With this in place the most dirft would come from noisy gyrometer measurements and the angle of corners was not always right.
The position estimation did not work as nice as I hoped. But based on the fact, that the estimation did not drift away at breakneck speeds, I concluded that at least you could use the algorithm for a speedometer. If you would add a "zero velocity update" based on unchanged GPS positions it would work even better.
It was incredibly easy to eliminate a major part of noise in this problem. It is such a trivial idea, that I was struck when I first had a look at the great results. And I am sure that a machine learning approach would just learn the transformation between the IMU and the car and then ignore measurements that are implying that the car would drive in impossible directions.
[1]https://gitlab.kitware.com/cmake/cmake/-/issues/18355
[2]https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p16...
[3]https://devblogs.microsoft.com/cppblog/cpp20-modules-in-cmak...
That said, I don't think that is that big of a problem compared to final compile time reduction.
EDIT: Disregard that, the preprocessor remembers the states of include guards. So there is literally no point.[1]
[1] https://gcc.gnu.org/onlinedocs/cpp/Once-Only-Headers.html
I would convert my entire codebase to modules in a second if the CMake Support was nicer.
[1] https://techcrunch.com/2022/04/22/google-facebook-apple-eu-l...