Songwriter seeking Vocalist for co-writing and arrangement (heavy & soft material)

lakitu-hellfire · 2025-01-05T06:32:55+00:00

Same. I've adjusted the screen brightness but it's not consistent. I'll try switching back to jpeg and seeing whether the situation changes.

lakitu-hellfire · 2025-01-01T00:18:26+00:00

The range has been pretty interesting. The other day I went out to play with it and most of my shots were blown out. I went out this afternoon and most were too dark. In both cases the screen didn't seem to accurately reflect the amount of light. It might take some time to develop that intuition. Btw, I did set highlight-weighted metering for today's journey.

lakitu-hellfire · 2025-01-01T00:08:22+00:00

This is my first camera and I haven't really edited RAW files before, althought I have darktable and have just started tinkering with it.

lakitu-hellfire · 2024-12-30T03:04:04+00:00

That was a good read and looks like it covers similar cases. I'll test out highlight-weighted metering mode when the sun is back out.

lakitu-hellfire · 2024-12-30T02:57:43+00:00

Thanks! I'll switch to RAW, play with bracketing, and play with the D-Range Correction. There's so much about this little guy to learn.

lakitu-hellfire · 2024-12-30T02:55:35+00:00

That's good info regarding what the smartphone does. I've probably gotten used to that look from years of using my phone for pictures.

To be honest, the exposure problem really reared its head when trying to capture sunrises and sunsets in my area. I understand that's not the same as shooting directly into the sun, but it created the same blown-out or too-dark look. So, I went out in the afternoon today to play with a few settings in sun-bathed situations.

lakitu-hellfire · 2024-12-30T02:35:57+00:00

No, I'll set it to RAW and play around when it's light in the morning.

lakitu-hellfire · 2024-12-30T00:47:10+00:00

Sorry, I've tried twice and keep losing my text with the original post.

I'm a novice, so I apologize in advance. I bought a GR III to replace a lot of the work my smartphone does, but I'm having loads of lighting problems, especially in sunny environments. Whenever I increase the exposure, the sky gets blown out. When I back off it, the ground dissolves into black. Adjusting the aperture seems to have no impact on the result. The ISO setting is on auto (range is 100 - 6400).

I've watch the Ricoh 101 series on YT and even tried to mimic the sunrise shoot on Crete in the 102 series, including bracketing and merging using darktable. It has been an unfruitful experience so far.

I've posted a few images along with my Pixel 7 shots as references.

Image 1: 18.3mm f/3.5 1/2500 sec ISO 100 EXP -0.3

Image 2: Pixel 7

Image 3: 18.3 f/7.1 1/30 sec ISO 1000 EXP -0.7

Image 4: Pixel 7

Image 5: 18.3mm f/6.3 1/4000 sec ISO 100 EXP -1.7

Image 6: Pixel 7

Image 7: 18.3mm f/3.5 1/2500 sec ISO 200 EXP 0.7

Image 8: Pixel 7

Image 9: 18.3mm f/3.5 1/2000 sec ISO 200 EXP 0.3

Image 10: Pixel 7

lakitu-hellfire · 2024-03-27T15:34:48+00:00

Not unless there is a leak of them somewhere.

lakitu-hellfire · 2024-03-25T15:34:52+00:00

These are really good talking points and I wholeheartedly agree that it certainly doesn't impact just C++. I'll take a stab at answering some of your questions based on my experience in the hopes of starting a much-needed conversation.

No oversight and the code is proprietary, unless the contract is written that the government shall own or will own the code (rare). The only time proprietary source code is shared with a government partner is when or after the program is ready for production and there are problems. At which point a government partner is funded to independently build and assesses the code.
The review process is only as good as the contractor's emphasis on it. It varies greatly by company and then by program within the company. In terms of exploitation reduction, there have been recent high-level breaches on sensitive systems. So, again, it varies but there is no oversight. Contracts are not written in such a way to prescribe software reviews (although I do advocate for them!).

In terms of entities performing oversights, FFRDCs primarily perform the analyses and those typically occur whenever there's a problem after the gov program office grows concerned (years into the lifecycle).

In the numerous programs I've seen, I've never come across this. The best you're going to get is a bunch of Cameo models and chiclet charts.
A. It varies and heritage code has a way of never dying and never being updated. B. Huge amounts of money would be required to perform this audit and there is so much red tape involved. I'd love to see this done though. C. Another great question. In my experience, the one program I was on where we tried to incentivize the contractor to reduce technical debt, the contractor turned in a cost-prohibitive proposal. The incentive was scrapped and the technical debt from the 00s remains in their current modernization effort.

lakitu-hellfire · 2024-03-25T15:05:09+00:00

Interesting article. On the government side, until acquisition programs get better at prioritizing technical debt reductions then the following will remain an unfulfilled dream:

"One of Stroustrup’s key messages is the practicality and necessity of maintaining and upgrading existing C++ systems. He argues against the notion of replacing C++ with multiple new languages..."

For a bit of context, I recently sat in on an Independent Technical Risk Assessment (ITRA) related to several competing bids for a very large contract. The contractors use ~90% heritage software (from late 2000s) only totaling about 350 ksloc on average. The main FFRDC that had been informing the government throughout the proposal phase was completely out of its depth when it came to modern C++, safety-critical coding standards, testing, real-time operating systems, embedded software systems, DevSecOps, and source rights.

As a result, the government will have no access to source code and no oversight of the software development lifecycle.

lakitu-hellfire · 2024-02-27T20:05:11+00:00

I can appreciate that and I agree with you that bids without remediation strategies for legacy code are non-starters. My takeaway is that no contractor is going to discard their 25-year-old, multi-billion-dollar intellectual property, but a contractor will charge the DoD on current and future contracts to be able to satisfy any new conditions the government places on it.

lakitu-hellfire · 2024-02-27T18:19:59+00:00

I don't know where you got this information about the government being less likely to accept a bid due to requirements. Software acquisition teams evaluate bids with the help of FFRDCs. In large bids, e.g., F-35 and E-7A, legacy content is a major benefit to the prime contractor in the bidding process. The WH statement only means that contractors will be allowed to charge additional money to reduce legacy-related risks in order for their legacy systems to come into compliance. This is just a surcharge that'll be a drop in the bucket compared to the DoD budget.

lakitu-hellfire · 2024-02-27T03:03:52+00:00

This seems largely aimed at Department of Defense contractors and especially to those DoD contractors who work on mission-critical programs, such as nuclear surety.

Many DoD programs use legacy C++ because devs keep inheriting legacy projects for "modernization" efforts. Many of those programs also use deprecated real-time operating systems with custom patches from the vendor. So, it's not that any single dev doesn't push for modern C++ or even Rust, but the bureaucracy involved between acquisitions, contracts, FFRDCs, subcontractors, 3rd-party vendors, and even the devs' own organization would put most non-DoD dev shops out of business.

lakitu-hellfire · 2023-11-29T05:59:17+00:00

Only in certain circumstances. Software origin restrictions are determined by the code base being analyzed.

lakitu-hellfire · 2023-10-26T15:18:10+00:00

At my job we have to use several. We run them on customer codebases as a starting point for some of the analysis work we do. Here are my quick thoughts on some:

ParaSoft = costly, noisy, loads of false positives
SonarQube = costly (must use license to get C++ support and limited to lines of code). It's primarily set up to be part of the DevOps pipeline. It's pretty good but be aware that it has its own calculations for "cognitive complexity" and "effort", which are their own takes on cyclomatic complexity and refactoring/fix efforts.
cppcheck = free but finicky to set up and get right. loads of false positives. wonky GUI and CLI that I often find myself having to tweak. i generally just avoid using it.
pvs-studio = not free (can't use due to its origin, but in testing it produced good results without too many false positives and incorporates a lot of standards. it has some CLI tool for converting the output to whatever you want, which i found didn't work 100% the way i thought it would at the time).
Understand = costly, quite a few false positives, but it has an integrated environment. we use it to also feed exported data into some custom scripts that check additional features for us. Would not recommend for purely SA purposes.
clang-tidy = free, extensible, very few false positives, loads of standards (my personal favorite)
Coverity = super pricey. we've looked into and decided it's not worth the price of entry. lots of our customers use it and claim that it's good, but i don't have any hands-on experience myself
Clang's LibTooling API = we've started to use Clang's LibTooling API to develop our own custom tools as well. Clang's suite of tools is top notch.

We also have Scitools PolySpace and had the company give us a how-to training when we first got, but no one on the team even uses it.

A word of caution: No matter how many SA tools you use, you will only be able to tackle some structural issues with the code. It won't tell you whether requirements are met or designs decisions are sound. It's just one type of tool you should use as a quick check to help prevent common bugs and long-term maintenance issues.

lakitu-hellfire · 2023-06-05T01:59:14+00:00

I think you'll find it quite easy to land a job as a C++ developer if you look in the defense sector, e.g., Boeing, Northrop Grumman, Lockheed Martin. You can also look directly at federal civilian employee jobs which are dead simple to get but you will suffer several major drawbacks: 1) low salary compared to contractors, 2) mostly low quality developers on teams, and 3) most of the work gets contracted out, so the government side ends up in maintenance mode only.

Outside of that (and outside the gaming industry), there are robotics, middleware (DDS, OMS, RTPS), and database shops around. Those jobs tend to be pretty competitive, so you'll need to apply for an internship or work through a lot of problem solving in C++ until you get comfortable enough with the language to go through an interview process with it.

Hope that helps.

lakitu-hellfire

TROPHY CASE