Programming language adjustments sound good on the surface but don’t really cut deep enough, as far as the problem domain is concerned.
This is both research and implementation of a military grade solution.
Think about it this way: both the electrical engineering and the mathematics you are combining are (a) cutting edge in their respective fields (for the most part) and (b) cutting edge in their combination. Finding good ways of expressing that Geometric structure in a programming language feature or as a subroutine library is 10 years and many more applications (read: real world tests) down the road from where original poster’s work takes place for the government.
And ipunchghosts seems to have encountered what other people in his position convey behind closed doors: The researchers are sacrificial pawns and even sacrificial chess queens. Your mileage may vary, of course.
Again, probably pretty naive take (and without regard to the amount of or quality of outcomes), but when looking at the way academic research occurs, thinkers are often exposed to failures and asked to explain them or expound upon the underlying philosophy -- rather than to participate in the full engineering cycle; that can take different forms such as hands-on development, but particularly in engineering, viewed with skepticism.
I think there's even a take that you can tease the patent system as a way to profit from failing to explain ideas effectively.
Edit: maybe the consideration then is what are the roles missing? if there's a way to improve off-the-shelf model performance faster than moore, what is it? scaling to teams that specify more specialized roles; simulation, model architecture / quantization specialist, systems-level, hardware-match specialist / minimization? some sort of way to compose, or perform operations on the content of models?
I guess im wondering if other researchers in DoD are having the same sentiment as me. I find it hard to believe they arent but it's something that not talked about much because from my point of view, there arent many researchers with 20 YoE left in the DoD. If i am wrong, point me to them as i want to join their ranks!
There was a Lenovo docking station compatible with the T420 (around 2012). The headphone Jack had shrieky noise on it whenever the Gigabit Ethernet connection got going. Took a while to figure that one out.
The other two docking stations were built differently and had the wires run somewhere else.
Be careful about generalizing about Boeing here; it's not really a good example. The door plug incident was entirely caused by managers, not bad engineering.
In this case, the managers knew that if they went back and removed the door plug then it would have to be inspected again. That would cost time, and the plane was already behind schedule. Their bonuses were in the line, so they got together to find a solution. The solution that they found was to skirt the inspection rules using semantics. They decided to have their employees loosen the bolts, shift the door plug a little, do the required work, and then put everything back. This allowed them to claim with a straight face that they hadn't ”removed” the door plug, and therefore it didn't need to be inspected.
Yes the root cause might stem from management but good engineering would not have the doors flying off... thus bad engineering. Regardless of everything else, engineers are responsible for their designs at the end of the day. (Yes when management only approves cheap unsafe designs)
Otherwise you are "just following orders" which is not a viable leg to stand on.
I disagree. First, remember that we’re not talking about doors here, but walls. Specifically, a door plug which is a type of wall segment that can be put into the space where room was left in the airframe for an optional door. If you cannot get that detail correct, maybe your opinion doesn’t count for much.
Second, the steps for assembly of an airplane are all very important. If any of them are skipped or left out somehow, the plane will break! You can’t engineer your way out of this problem either: the more ways you add of attaching that door plug to the airframe, the more possibilities there are for mistakes. That’s why the assembly process requires one team to install the plug and another team to verify that installation was completed correctly and according to the specifications.
Any time you have managers using semantics to weasel their way out of the inspections that verify that the plane was assembled correctly, that’s the mistake. Full stop. Fire those idiots.
I think what happened is, Boeing codified all these labor-intensive manual processes back when they were riding high. The planes were selling well, they were state of the art. Now, 30 years later, it takes the same amount of effort to put everything together without mistakes, but the relative value of the finished product is less.
Not sure what that has to to with writing software. If I take your perfectly written code and run it on bad hardware that corrups memory and a CPU that does math wrong (aka don't tighten the bolts down all the way), it's going to cause problems, regardless of if it was a #1 or #2 type engineer that designed the system.
"The data is most valuable when it is in the mainrack. Your Facebook data isn't nearly as useful without the ability to post to the pages of your friends. Your Google Docs files aren't as useful without the ability to collaborate with others. Dynamic state matters; it's the whole point of having computers because it allows automation and communication."
Data tables, data tables, and data tables. Data tables over flow-charts . Fred Brooks all the way down.
Well, in a rather simplistic world view the argument boils down to the following, which does seem to happen:
(A) There are two dominating uses for large computers:
(Use 1) HPC a.k.a. Floating point numbers, Fortran, LLM, CERN, NASA, GPGPU, numerical analysis, etc. These examples all fall into the same bucket at this level of (coarse) granularity.
Dominating use number (2) is accounting. Yes accounting. Append-only logs, git, Merkle trees, PostgreSQL MVCC (vacuum is necessary, because it boils down to an append-only log that is cleaned up after the fact — see also Reddit’s two giant key-value tables), CRDTs, credit cards, insurance, and accounting ledgers.
(Use 2) is dominated by the CAP theorem and favoring consistency over availability during network partitions, because it has to provide and enforce a central coherent view of the world. Even Bitcoin cannot fork too hard for account balances to still be meaningful. (Philosophical nit picking: How does this relate to General Relativity and differential geometry? Can this then only ever be "local" in the sense of general relativity?)
This is where mainframe style hardware redundancy always enters the picture (or your system sucks). Examples: (i) RAIM (RAID for RAM), (ii) basically ZFS, and (iii) Running VMs/Docker containers concurrently in two data centers in the same availability zone (old style: two mainframes within 50 miles and a “coupling facility”)
(B) All other uses like playing Minecraft or Factorio, smartphones, game consoles and running MS Excel locally are rounding error in the grand scheme of things.
Note: Even oxide computers seems to be going down this route. IBM ended up there, because everybody who can pay for the problem to be fixed makes you fix your hardware and processes. Period.
In the end all processes and hardware are locked down and redundant/HA/failure-resistant/anti-fragile. It is a mainframe in all but name by being isomorphic in every conceivable aspect. This is Hyrum’s law for our physical and geometric environment. The other systems die out.
Even Linux user space ABI, JVM, SQLite, cURL, and (partially) JavaScript are so focused on backwards compatability. Everything else breaks and is abandoned. Effectively every filesystem that isn’t at least as good as ZFS is a waste of time.
(D) Look at what MongoDB promised in the beginning and what they actually ended up delivering and what problems they had to solve and how much work that ended up being.
Be wary of the bounds of your confidence intervals.
Excel sheets got too large for my personal projections. Built a super simple static web app[1] as a replacement. It handles inflation better and provides a (very) simple monthly mortality model. It shows you select quantiles and the median(!). VaR and CVaR didn’t yield obvious insights and were removed. It’s free.
Have about a dozen happy users already.
Really think through your CAC, LTV and outgoing cash-flows.
Heretical idea: Pour money or cash into QA and watching your customers over their shoulders to solve their actual problems. Not what you think or hope their problem is.
If you have questions, then please, feel free to ask.
Programming language adjustments sound good on the surface but don’t really cut deep enough, as far as the problem domain is concerned.
This is both research and implementation of a military grade solution.
Think about it this way: both the electrical engineering and the mathematics you are combining are (a) cutting edge in their respective fields (for the most part) and (b) cutting edge in their combination. Finding good ways of expressing that Geometric structure in a programming language feature or as a subroutine library is 10 years and many more applications (read: real world tests) down the road from where original poster’s work takes place for the government.
And ipunchghosts seems to have encountered what other people in his position convey behind closed doors: The researchers are sacrificial pawns and even sacrificial chess queens. Your mileage may vary, of course.
Edit: Typo
reply