HN user

KyleJ61782

54 karma
Posts0
Comments22
View on HN
No posts found.

My company does most of our development in Delphi, but unfortunately that means that crash dumps are very difficult or impossible to utilize with the embedded Borland/Embarcadero TDS debugging information. I wrote a utility that extracts the TDS info from a Delphi executable and uses an LLVM debug info library to write out a PDB and also modify the executable to point to that PDB.

The source can be found here: https://github.com/powerworld/TDSToPDB

For all intents and purposes, yes. Besides making software easy to install, package managers figure out all the dependencies that a given package requires and install those as well. Can you install yum/dnf on Debian? I'm sure there's a way to do it. But good luck handling all the dependencies for a given package. Plus, there will be file conflicts when dnf installs a base dependency that apt already installed.

In other words, nothing good comes from trying to install two different package managers on one system.

That was already a possibility even before all of this DoH publicity. Mozilla, etc. pushing DoH publicizes it's availability, but there was nothing in the past preventing malware from tunneling all sorts of traffic over HTTPS. DNS inspection isn't an end all, be all for malware security. It just gets the low hanging fruit.

Using the NTDLL calls breaks stuff because NTDLL doesn't understand anything about the overlaid subsystems. NT was originally designed to support multiple subsystems in addition to Win32, like the Interix (POSIX compliant) subsystem and the OS/2 subsystem I believe. I think (I could be wrong on this) that this was possible by switching the system call table depending upon which process was currently active (doable by switching the system call vector).

Technically the Windows native layer supports fork()-like abilities, but the problem is that the Win32 subsystem and dependent layers (GUI, etc.) don't have fork() copy-on-write capability. So even if you were able to fork a process, you'd still have to deal with duplicating all of the stuff built on top. In fact, the old POSIX compatible subsystem layer utilized this functionality to actually provide a compliant fork().

Of course this all ignores the fact that Win32 processes are heavier duty than Linux processes (though I don't know if that's due to Win32 subsystem overhead or not). Look at any benchmark and you see an order of magnitude difference in process creation times. You're much better off creating threads instead.

> But I and I'm sure many others would not be focusing upon that, though I can appreciate that mentality due to the way media/tabloids cover such and all issues in life

That's a personal attack quite out of order.

Not really. It's just a societal commentary on how we've conditioned ourselves by the media we consume into passing quick blame instead of taking a slow, reasoned approach to analyzing the event, seeing the compounding factors at stake and only in the face of gross negligence assigning blame.

This. Very much this. In the presentations I've seen on the matter, the most vulnerable systems are those measuring and carrying telemetry back from various meters around the power system. One doesn't have to directly compromise the system to have an effect. Simply providing bad data to automated protection systems could be enough to cause instability.

Primarily it's due to function overloading. Different implementations may use different means to consistently and uniquely "mangle" function names on symbols to uniquely identify them in the library export. This mangling depends upon numerous factors, including parameter types and calling convention (if there are multiple conventions on a platform).

The size of the executable doesn't really matter after the first load as subsequent loads share the mapped section so it doesn't need to be loaded from disk again. Loading an executable multiple times after the first time really shouldn't take all that long from an OS perspective...just some mapping of shared pages.

Honest question: do you have a real-world example that indicates that the extra pointers added due to multiple inheritance actually results in performance degradation due to extra cache pressure?

I concur with the description of the Delphi implementation, as I've navigated it numerous times myself. I guess I don't understand the author's negative tone with regard to the C++/Delphi implementation. There's going to be overhead with any choice made and C++ and Delphi made the choice to sacrifice memory usage for speed. Furthermore, the only part that really scales with the number of objects is the extra vtable pointer for each implemented interface in each newly constructed object. Hardly a significant overhead in today's memory-prolific computing environment. Also, pointer fixup thunks and unconditional jumps are easy to speculatively handle.

Within galaxies, however, gravity dominates dark energy expansion, right? If so, with enough measurement accuracy shouldn't we be able to look for standard candles within our galaxy that either show or don't show said mass differences while compensating for any shift due to relative motion? I'd think that given enough accuracy we'd have something that's testable eventually.

Instead of looking into CBT, you may try looking for therapists who utilize Solution Focused Therapy. I found one who approached things that way and found it to be tremendously helpful. She approached things initially from a very standard inventory of my family history, personal values, etc. and then tended to let me direct my counseling until I realized I had reached a point that I was ready to stop my regular sessions. If you have any questions, please don't hesitate to send me a PM.

Not to mention that it gives an easy way for those of us with status access to a higher tier/priority of internet which is handy for streaming. Particularly when I'm staying in a hotel for over 60 nights a year.

They were definitely defrauded, but they weren't particularly shrewd here. Pumping the brakes a bit and taking a bit of time to consider all of the legal documentation almost certainly would have saved them. When a deal seems to good to be true, it almost certainly is. Never sign a document unless you fully understand what it is: what rights you're giving up and what legal declarations you're making.

Perhaps it's not abundantly clear, but I'm trying to draw a distinction there. I get that there are things like cancer that cannot be sufficiently financially prepared for. However, for things like needing a new roof, car tires need replacing, etc., that is precisely what contingency money is for. If you cannot save sufficiently for said expenses, it's time to consider a downgrade on that particular item until you can, or curtail other non-essential expenses for a while.

Agreed. This feels a lot like the home lending crisis leading up to 2009. People taking out loans for far more than they could afford with interest only loans, ARMs, etc., or taking out large home equity loans for consumer purchases. What it speaks to is a huge lack of financial literacy.

I do feel for people in this situation, particularly those who are driven to the home equity loans due to unfortunate events, like cancer, in their personal lives. But I feel that it needs to be said that there's a not insignificant number of people who are caught in these situations precisely because they failed to plan and have contingency money set aside, instead spending to keep up with the Joneses.

I think it's important to understand that while everyone has conscious and unconscious biases, it's not true that recognizing that fact is the same as assigning blame. The idea is to better know one's self, to try and understand one's own bias (to the best of one's ability, that is) in order to try and apply correctives when making decisions involving people who are different than we are.

It's when we actively press into these biases that we hold and steadfastly cling to them in the face of contrary evidence that we become guilty.

Now I'm not claiming that having bias is a good thing, it's quite the opposite. I am saying, however, that having bias does not imply culpability.