IT/Software career thread: Invert binary trees for dollars.

I've been debugging an issue for a week now. It's known what the problem is - a hardware interface is not up in time that another piece of firmware is trying to poll temps on the CPU. But that other firmware is keying the end of Memory Init to start polling DIMMS AND CPU. So they want a spot in the code where both are available, but every place I find is "too late" in BIOS boot.

This is one of those problems where there isn't an easy way to debug so I'm literally throwing darts at a board.

Boooorrinnnng

Getting deep in the hiring process with RedHat... The position sounds great on paper, is a 25% raise and I'd keep my clearance, but for some reason my gut feeling is that its going to become tedious and be not fun very quickly...

alavaz said:

Getting deep in the hiring process with RedHat... The position sounds great on paper, is a 25% raise and I'd keep my clearance, but for some reason my gut feeling is that its going to become tedious and be not fun very quickly...

Click to expand...

Its going to get IBMiified and will become complete horseshit.

What would you be doing at redhat that requires a clearance?

Red Hat does a ton of consulting with DoD

chaos said:

Red Hat does a ton of consulting with DoD

Click to expand...

You mean IBM. Red Hat is dead and has turned into IBM with an old respected name attached to it. Nobody buys IBM anymore. Soon as the current old boys pass on IBM will die as the era of "nobody got fired for buying IBM" is over.

True, I forgot they bought them out. I've been out of the govt so I'm not sure what the impact of that will be, at least on the govt side.

chaos said:

Red Hat does a ton of consulting with DoD

Click to expand...

Gotcha

We used VxWorks specifically so I had no contact with any real OS's on my end

Vinen said:

Its going to get IBMiified and will become complete horseshit.

Click to expand...

Pretty much my thought as well. I'll probably wind up turning it down.

Vinen said:

You mean IBM. Red Hat is dead and has turned into IBM with an old respected name attached to it. Nobody buys IBM anymore. Soon as the current old boys pass on IBM will die as the era of "nobody got fired for buying IBM" is over.

Click to expand...

I think IBM is a solid 3rd (behind AWS and MS) as a cloud service provider. Something like $11 billion annually (about half of MS/AWS but 5-6x 4th place).

alavaz said:

I think IBM is a solid 3rd (behind AWS and MS) as a cloud service provider. Something like $11 billion annually (about half of MS/AWS but 5-6x 4th place).

Click to expand...

Softlayer is just a Managed Service. I wouldn't compare it to AWS/Azure/GCP.

It's just "nobody got fired for buying IBM"

TJT said:

What is this, "nobody got fired for buying IBM" phenomenon?

Click to expand...

Basically with IBM you're supposedly getting not only a great stable product but all the support with it too. It's actually a quote directly from IBM and I'm assuming Vinen is making fun of that

I've worked on Mainframes for over 7 years, now.

IBM has done nothing to try and grow its Z/OS platform or develop anything modern of significant value to interface with their old technologies, if anything they've continue to intentionally commit the same mistakes at every new opportunity. Working on a Mainframe essentially hasn't changed in the last 40 years, IBM goes out of the way to stifle resources. When I started at my position I looked for resources where I could pick up on their environment and learn their languages, but IBM doesn't want to any type of free resource or platform that a burgeoning developer could use for learning. You either have to look at a non MF flavor of COBOL, or try and setup a Hercules emulator if you buy a Z/OS License. So no developer resources, a ridiculously outdated editor, and persistent desire to stifle anything remotely open source, and try to force continued mainframe interaction, as opposed to trying to innovate into a Post Mainframe world.

They''ll probably try to jam Red Hat onto the Mainframe as a Unix alternative or something pointless.

Yeah, don't trust anything IBM.

Oh and that bull shit about Mainframes never going down...firstly the CICS regions are recycled every day, its common practice to IPL the entire system once a week standard. The ability for one developer, or one application to completely throttle the system is just as much an issue now as it was then.

Whenever you want to do a DB2 transaction from outside the Mainframe, via ODBC or JDBC, or HIS library, or what have you an Enclave is created that estentially holds the conncetion data for the Query...sometimes this Enclave just sits there eating the paging file, long after the connection was closed, with no way for the average developer to know, or let alone even see that its still open.

TJT said:

My only recent experience with IBM shit is IBM API connect. Which GM required you to use to interface with a lot of our internal shit. But holy fuck was that thing a piece of shit. It also didn't have documentation of any kind. Like, I was looking at it trying to figure out how it worked. I created my API thing in it and didn't really understand what it wanted. Their only documentation on their site for the product was, "click the create button to create a new API." Well I got that far already lady, what else do I need to do?

When I did figure it out it still perplexes me as to why it exists. You have to create your API calls to interface with some of our internal REST. However you must do this in little snippets of Javascript (even if your project is in some other language). Then you must use the API Connect GUI to create like... almost a flowchart or something of triggers and other bullshit.

I don't really understand the value of such a thing unless you have someone managing your API calls who had no other part in the application and has never coded anything before. Which I guess is possible... but if one broke they wouldn't know how to fix it. I was always told that API connect is a middle man that allowed our security people to manage security on one thing. I can kind of understand that but god damn.

Click to expand...

I haven't used IBM's offering, but at one of my previous jobs we used an Oracle product that did something similar. I think the original idea was to create web API's for applications that didn't have web APIs and create sort of a standard interface for all of them. It always seemed kind of counter-intuitive to shove an already good REST api through middleware though, but gotta get that money's worth.

Need some ideas from a security guru on something:

Our software is installed on a customer's server by delivering installation files to it and running the setup executable -- you know, like any old fashion Windows application. This also applies to updates to the application as well -- install files are copied over and setup ran which then updates the existing app.

There are parts of our application that need encryption keys in order to send sensitive information to something downstream. These encryption keys may need to be changed or added to the application over time. The problem is, how do we deliver these updates in a secure manner? Up to this point they are embedded as part of a database update script, which of course is not good since they are sitting there in plain text. This isn't so much of a problem if the installation files are deleted afterwards, but there's no guarantee that some doofus won't forget to do this.

So we're trying to think of some (simple) way to get this data into an existing instance of the application without having it exposed along the way -- this includes as plain text in a db update script (which is the way it is now) or even a .dll file which could be disassembled.

The three options proposed are:
1) Include an encrypted+password protected .zip archive that contains the data, then the installation guy supplies a password so the install program can extract it
2) Ship a SQlite encrypted database with the install program that has the data which, like #1, requires a password in order to be accessed.
3) Just use some method to obfuscate the keys making them difficult to discern if the dll is disassembled. This wouldn't be as secure as the above options obviously, but good enough(?).

Is there anything I might be overlooking?

PS. our setup program cannot reach out to an external resource for data. It all has to be local.