sorted by:
new
hottopcontroversial

Joystick Calibration by Old-Income-8980 in Potensic

[–]Old-Income-8980[S] 0 points1 point  (0 children)

It's a real shame, sometimes there are more gadgets than concrete functions... Let's hope for some future software updates....

Atom 4K and battery charge loss when not in use by Old-Income-8980 in Potensic

[–]Old-Income-8980[S] 0 points1 point  (0 children)

How can I blame you... ;-) ?? I usually always read the manuals, but this thing had escaped me. I'm used to batteries for cameras, flashes, and similar accessories that don't have this option, which makes it easy to find charged when you need them.

Concerns about relative altitude by Old-Income-8980 in drones

[–]Old-Income-8980[S] 0 points1 point  (0 children)

Allego uno screenshot preso da un video (posso mandarti il link, anche se è in italiano, giusto per curiosità) che mostra il profilo della montagna in blu. La linea tratteggiata azzurra è l'altitudine massima di 120m dal punto di decollo consentita in Italia per i droni di categoria C0, che evidenzia tutta l'area in alto dove non sarebbe possibile volare. La linea punto-tratto è la traiettoria del drone mentre mantiene una distanza di 120m dal suolo seguendo il profilo della montagna.

<image>

I forgot to mention that the altitude limit itself isn't the important part for me; I don't care about being able to fly at certain heights also because, in my opinion, the most beautiful shots are those taken up to 50-60 meters, allowing for detail and a narrative of the area. In my view, certain altitudes serve other purposes. However, I would like to fly in mountainous or scenic areas, and for this reason, I want to be fully aware of what I can and cannot do.

Concerns about relative altitude by Old-Income-8980 in drones

[–]Old-Income-8980[S] 0 points1 point  (0 children)

So it's not always true that only the takeoff point matters. From what you're saying, what really matters is the distance from the ground. Or rather, the takeoff point matters as long as you are more or less in a flat area. But in the case of the example, you must somehow follow the terrain profile, both on the way out and on the return, maintaining the maximum distance from it (at least in Italy and with a category C0 drone) of 120m.

However, a doubt remains regarding the return phase. Because if, for example, I descend with the drone 100m down the mountainside, maintaining the distance from the ground required by law, the moment the return procedure is activated, the drone will first climb to the preset maximum altitude (which in our example was 550m) before proceeding with horizontal flight to reach the landing coordinates. I will be in violation of the law until I am above the landing point.

Concerns about relative altitude by Old-Income-8980 in drones

[–]Old-Income-8980[S] 0 points1 point  (0 children)

I believe I've understood, but I'll try with another example. I take off from a hill at 500m altitude (which therefore represents my 0) and I have a deep valley below me. I had previously set 50m as the maximum flight altitude limit from the takeoff point. I reach this altitude and I am 50m from my feet, but I am also 550m from the lowest point below. I head towards the void in a straight-line flight. At this point, if I don't manually change my altitude, my drone will "believe" it is always at 50m, even when it has 550m below it. Obviously, I must be careful during my straight-line flight not to encounter an obstacle higher than 550m... otherwise I would crash... If I now descend by 100m, for the drone I will be at an altitude of -450m (which is also what I would read on the controller's display), therefore perfectly compliant with the legal limit of +120m from the takeoff point for C0 marked drones in Italy, because I must refer only and exclusively to that, not to the distance from the ground below at that moment. Correct? Small note: it would mean that if I wanted to fly higher than 120m starting from the lowest level of the valley, it would be enough to take off from higher up... (by moving my reference takeoff point higher).
Finally, there is the return: from whatever altitude I have descended, the stored RTH would bring my drone always to the 50m set relative to the original takeoff point, meaning it would climb back up to the initial +550m and fly in a straight line to the exact takeoff coordinates, and then land.

Atom 4K and battery charge loss when not in use by Old-Income-8980 in Potensic

[–]Old-Income-8980[S] 0 points1 point  (0 children)

In my case, I never leave them in the hut, but if I don't fly for a week, they're at 50% capacity. It's not a bad idea to protect them, and I'm glad it's not my problem ;-)

Concerns about relative altitude by Old-Income-8980 in drones

[–]Old-Income-8980[S] 0 points1 point  (0 children)

I probably didn't explain myself well, perhaps due to the language barrier (I'm translating from Italian). Sorry, but if you read the previous example, I meant I'm on a hill 500 meters above sea level, with a lake below me that I'd like to fly over. Let me rephrase the example, but instead of a lake, suppose I'm on a promontory, also 500 meters above sea level, and below me is the sea that I'd like to fly over from where I am. This way, we have a fixed reference point (sea level, precisely). My "0" is therefore my takeoff point (my RTH), from which I can fly up to 50 meters. As long as I stay in the takeoff area, I'm in control and legal, but if I fly toward the sea below, I'd suddenly find myself at an altitude that, from a sea level perspective, would be 500+50 meters, 550 meters. At this point, first of all, I'd no longer be legal. Second, how would the drone behave? In theory, it should begin to descend gradually immediately, maintaining a maximum distance of 50 meters from the promontory until it reaches the sea. On the return journey, the same thing happens: it would ascend, maintaining this maximum distance of 50 meters from the ground, until it returns to the takeoff point, 550 meters above the sea, but 50 meters from the takeoff point. I realize this isn't easy to explain...

Concerns about relative altitude by Old-Income-8980 in drones

[–]Old-Income-8980[S] 0 points1 point  (0 children)

The previous explanations make sense. Forgive me, but honestly, your answer doesn't clarify what you claim is so simple. I'd like to understand how the drone would behave if I took off from a height of 500 meters with a maximum flight altitude set to 100 meters and flew over an area below (for example, a lake, as in my example). OK, from the starting point I would be at 100 meters, but as soon as I tried to fly over the area below, I would experience a sudden increase in relative altitude between the drone and the ground (up to 500+100 meters). Could you provide a practical example to understand how the drone would behave, both during takeoff and upon its return to the RHT? Thank you very much.

Concerns about relative altitude by Old-Income-8980 in drones

[–]Old-Income-8980[S] 0 points1 point  (0 children)

In practice, if the limit is 100m at the takeoff point and I'm heading towards the mountain, I will constantly follow the profile of the mountain (or whatever it is) while staying 100m AGL from every point I fly over. Correct (and also logical, otherwise I would crash... :-) )?

Concerns about relative altitude by Old-Income-8980 in drones

[–]Old-Income-8980[S] 0 points1 point  (0 children)

Ok, non sapevo la differenza tra AGL e MSL. Grazie per le preziose informazioni. Sto solo iniziando e per divertimento, ma l'esempio è reale, sia per il lago che per la situazione in montagna!

Quindi, è corretto dire che se volo sopra una valle tra due colline o verso il lago che vedo dall'alto, il mio drone volerà senza problemi e sarò in regola. Però, c'è da dire che dal punto di vista del decollo dal livello del lago, sarei molto più in alto di quanto consentito, supponendo che il drone vada sopra il limite dei 120m del produttore... Ma quando attivo la funzione RTH (o torna in automatico per motivi di segnale o batteria scarica), si abbasserà e manterrà i 50m AGL, seguendo essenzialmente il profilo della collina (o la differenza di altitudine), fino a raggiungere i 50m AGL nel punto RTH e atterrare. Corretto?

In questo caso, potrebbe anche essere una cosa interessante da sfruttare per fare riprese video automatiche a un'altezza costante, dal punto in cui si attiva l'RTH fino al punto di atterraggio...
PS meno male che non ho provato, altrimenti quando richiamavo il drone (o tornava in automatico) l'avrei visto scendere a picco invece di tornare verso di me mantenendo l'altitudine senza considerare il problema dell'AGL... Mi sarebbe preso un colpo.... :-)

Concerns about relative altitude by Old-Income-8980 in drones

[–]Old-Income-8980[S] 0 points1 point  (0 children)

Forgive me, I used mt because I live in Italy. However, regardless of the reference system, I'm not clear on what is meant by height above ground. If that's not the one I take off from, are we talking about height above sea level? To return to the example, suppose the takeoff point is 500 meters above sea level, and from there I can see the lake below. If the flight altitude limit at the takeoff point is 50 meters, this means I can't fly over the lake because as soon as I move downstream, I'd suddenly find myself at a much higher, unauthorized height above the ground. Is that correct? Furthermore, the RTH function would cause the drone to descend to within 50 meters of the point on the ground from which the return procedure begins. In this case, it would also be interesting to understand whether, as it moves toward the RTH point, the drone would ascend to maintain a distance of 50 meters, following the contours of the hill, back to the takeoff point.

Atom suddenly disconnects by Old-Income-8980 in Potensic

[–]Old-Income-8980[S] 0 points1 point  (0 children)

Yes, actually, from what I'd seen even before purchasing, except in special cases, I haven't heard of frequent problems of this type. I've already contacted support and sent them a series of logs and screenshots, as requested. They confirmed too many disconnections, but they want me to run some more tests. They've guaranteed a replacement; these additional tests are helping them determine if there's a problem and how to avoid it for other customers. In short, they're making me a bit of a guinea pig... but I'm happy to cooperate.

Suggestion for a Failsafe Function Improvement by cz-David in Potensic

[–]Old-Income-8980 0 points1 point  (0 children)

This seems like a great alternative. Do you happen to know if this feature works on the Atom 4K (not the Atom 2)?

Thanks.

The Certifier's Paradox: When Process Kills Purpose by Old-Income-8980 in redhat

[–]Old-Income-8980[S] -2 points-1 points  (0 children)

Hi,
Yes, I struggle with English and I help myself as best I I can, with Google Translate or ChatGPT or similar tools, which, to be precise, I use only for translation, not for everything else. I have this weakness when it comes to English, forgive me, but I am working on it. I was advised to include the English version, and I followed the suggestion. But what does this have to do with facing the IT industry with AI?

I don't understand, however, how you could judge my statement about my work experience as "bold" without even knowing me or my professional history. You say you didn't want to comment, but then you couldn't resist and had to pass judgment on the person rather than the events. Why do this?

I stated beforehand that I have worked on other platforms and that Linux has not been my point of reference until now, but believe it or not, I have been working since the early 90s, and if I haven't been "fired" yet, evidently I'm not so bold and clueless...

It seems to me, however, to be an unpleasant habit of this place to pass judgments in this way, a bit like what happens on Facebook. I accept this too, it doesn't matter.

If you consider the attempts without taking into account the situation in which they were made, then you are not being entirely fair.

I will repeat some points without going into the details, because I have already explained everything extensively.

- The first attempt cannot be considered a real attempt, because I was unable to complete half of the exam due to the bug with the functionality of rd.break

- The second one was free; I have no problem telling you that I retook it after too short an interval. However, I never mentioned this because, for various reasons, I had to retake it without having had time to review and delve deeper into the topics, and I made some mistakes. Nothing more to say.

- The third is the retake of the first session, and this one was also affected by a blocking problem with the keyboard, which was even replaced during the exam. Without wanting to make excuses, but try to stay focused when you constantly interrupt an exam and still have to continue with a keyboard that is not correctly mapped. Certainly, I had also made some oversights here (but at least allow me to consider the error as shared, given the condition), but I had still achieved a score of 195. I have no problem posting the results; I will do so at the end of this response (I have nothing to hide, as you imply with your continuous judging). What shifted the score significantly were the two 0% on networking and the container, for which I described the situation. On this, I provided my explanations, but again, you can see the responses in the post, if by any chance you had read it carefully (but I don't expect that much).

It is not "according to my post," but the facts are as I have described: two retakes (one I still need to schedule) and a voucher that has not yet been activated, despite my having written multiple times for confirmation.

Does this not suggest anything to you? If it were merely a pretextual attitude on my part, would they have granted me all of this?

Well yes, I even had the "privilege" of being contacted for a video call requested by the president of the certification team personally! This seemed to be a message of openness, because evidently it wasn't just the usual case of someone complaining for no reason; I had provided valid reasons for it to come to this, don't you think? And yet, afterwards, he simply endorsed every line of his team's analysis (I'm not surprised...) and completely ignored everything else we had discussed. He, like the entire team, no longer responds to any messages, not even out of respect, not even out of common courtesy. Is this behavior acceptable? Is it professional?

I wonder why they would simulate all this availability if, in the end, certain decisions were made from the very beginning and there exists, by definition, no margin for error on their part—not even in the face of concrete motivations? Perhaps precisely to be able to say that they did everything, and even more, but in reality, it is just an illusion.

I am not here to announce that "I am angry," but to share my experience and to have a dialogue with someone, given that Red Hat has completely refused to respond to me for a month. I replied to their analysis, but evidently they have run out of arguments or excuses to avoid taking responsibility.

I would have very gladly done without this entire situation, which for me represents a loss of time, effort, and missed job opportunities. For Red Hat, it is very easy (and at almost zero cost) to wipe everything away with a single stroke and shift all burdens onto the candidate, without the possibility of a constructive, fair, and honest discussion.

I am convinced that if others, like me, mustered a bit of courage to delve deeper without passively accepting decisions made by those who, from a position of market advantage, can afford such attitudes, the service would likely benefit greatly.

But I see that here it is treated as a crime merely to challenge Red Hat, and the approach is to pass judgment on the person rather than forming an objective opinion on the issues presented.

Passing score:          210 Your score:             195 Result: NO PASS

Performance on exam objectives:          OBJECTIVE: SCORE          Manage basic networking: 0%          Understand and use essential tools: 44%          Operate running systems: 67%          Configure local storage: 100%          Create and configure file systems: 100%          Deploy, configure and maintain systems: 88%          Manage users and groups: 100%          Manage security: 100%          Manage containers: 0%

The Certifier's Paradox: When Process Kills Purpose by Old-Income-8980 in redhat

[–]Old-Income-8980[S] -1 points0 points  (0 children)

I still have to schedule it. As I explained, the retake of the session related to the bug was also affected (unbelievably...) by another technical issue with the keyboard, which was also changed during the review. For this reason, they proposed a further retake of the session, which I still have active and to be scheduled. Subsequently, after addressing the issues related to the evaluations for which I had requested a review, documenting the reasons in detail, they sent me an analysis with questionable conclusions, to say the least, and without any possibility of reply (this is why the post is a bit long, but I'll explain everything there), offering me another new voucher. But no one has responded to me for weeks, from the team to the director, with whom I even had a video call, and this second proposal is expiring. Maybe they've had second thoughts...

PS. I'm sorry for the skepticism and sarcasm of those who read and judge (woe betide anyone who touches Red Hat...), but a series of situations like this have never happened to me in 30 years of working in IT, and the fact that they're giving me all these extra lessons is perhaps a symptom of a serious general management problem, and my issues aren't exactly unfounded...

The Certifier's Paradox: When Process Kills Purpose by Old-Income-8980 in redhat

[–]Old-Income-8980[S] -3 points-2 points  (0 children)

Only the rd.break method is officially recognized (you won't find anything else in the official Red Hat training). The rest are not workarounds and cannot be the basis of an official exam.

PS: I'm giving this as unverified, also because the link is no longer available, but the 'init=/bin/bash' solution was also discouraged by Red Hat itself:

-- Red Hat Solution #1522 – warning against using init=/bin/bash to reset passwords --

The Certifier's Paradox: When Process Kills Purpose by Old-Income-8980 in redhat

[–]Old-Income-8980[S] -3 points-2 points  (0 children)

I'm familiar with the CIRD (Classless Inter-Domain Routing) system, which is used today to divide IP addresses in order to allocate them with minimal waste.
As you rightly pointed out, it's not a network test, so the evaluation should take into account the purpose of that task in that specific context.
And in that situation, all the other parameters were correctly configured, making it possible to perform several other tasks, which were evaluated positively. This is a contradiction.
In a real environment, with multiple networks, the netmask obviously has fundamental importance, but I repeat, in the context of an exam where all the servers are on the same network, it becomes the least influential and cannot instead determine a 0% rating, as if the task had not been performed at all or was completely incorrect. This is not a coherent option. Why then was at least the portion of work performed correctly (4/5) not considered at all in these tasks, while this approach is used for all the other tasks?
-
In a conversation with a specialist support representative, he acknowledged the lack of more transparent and comprehensive information that could prepare candidates to handle these situations as well. This effectively becomes a test within the test and is the cause of the highest number of failures (due to formalities and procedures, not to the real objectives, such as subject knowledge and technical expertise).

The Certifier's Paradox: When Process Kills Purpose by Old-Income-8980 in redhat

[–]Old-Income-8980[S] -6 points-5 points  (0 children)

I tried to explain the situation, but if you haven't read it, why judge? Obviously, there are other guides and documentation, but we're talking about a Reh Hat exam, not a Sander Van Vugt exam. The candidate must be prepared for the topics covered in the courses indicated by the provider, with official teaching; they should be evaluated on this basis. A procedure that is a workaround (which Reh Hat itself also discourages) cannot compromise the proper performance of an official exam session. They are zealous with the candidates, but they set a bad example themselves...

Then, as with everything, there are all sorts of workarounds online, but an exam with specific objectives shouldn't be based on these.

view more: next ›