stevecrox @ stevecrox @kbin.social

Posts

2

Comments

72

Joined

2 yr. ago

If you read the reports...

Normally JPL outsource their Mars mission hardware to Lockheed Martin. For some reason they have decided to do Mars Sample Return in house. The reports argue JPL hasn't built the necessary in house experience and should have worked with LM.

Secondly JPL is suffering a staff shortage which is affecting other projects and the Mars Sample Return is making the problem worse.

Lastly if an organisation stops performing an action it "forgets" how to do it. You can rebuild the capability but it takes time.

A team arbitrary declaring they are experts and suddenly decideding they will do it is one that will have to relearn skills/knowledge on a big expensive high profile project. The project will either fail (and be declared a success) or masses of money will be spent to compensate for the teams learning.

Either situation is not ideal

I have always had 1 question.

In voyager we see the Borg have thousands of ships of varying sizes and control a vast area of space. Voyager is able to take down spheres and small cubes.

Yet in Wolf 359 a single cube attacks and destroys hundreds of star fleet vessels. If a single cube is able to have that level of effect why didn't the borg commit a larger fleet?

You have the same issue in First Contact, they only commit 1 cube.

Considering how difficult the federation finds holding them back, attacking with 3-6 cubes would seemto assure victory

Because the Tories have upset everyone internationally, so it isn't really an option. If you've been paying attention the EU has been playing a bunch of jobsworth type games with the UK.

Notice how he will do this in 2025, when the current agreement is up for renewel rather than immediately.

You also have the fact rejoin isn't winding the clock back to 2016, firstly we would loose all of our opt outs, things like the rebate, the euro, etc.. I don't think the reality would actually be popular.

Secondly the UK blocked a number of things like the EU Army (personally I think its a terrible idea, countries that don't spend enough looking to combine to "save" money) so it isn't the same EU.

Lastly see above mentioned jobsworth behaviour, I would not be surprised if the EU demanded the UK to complete all the paperwork of a new joiner and drag the process out as long as possible (it takes 10 years for most countries).

Far better to put the UK on a stable footing and then ask if EU membership is something the UK still wants. It took the 13 years to get to this point, so its unlikely everything will be fixed during the next government. So why bring something like rejoining up?

The GAO has performed an annual review of the Space Launch System every year since 2014 and switched to reviewing the Artemis program in 2019.

Each year the GAO points out Nasa isn't tracking any costs and Nasa argues with the GAO about the costs they assign. Then the GAO points out Nasa has no concrete plan to reduce costs, Nasa then goes nu'uh (see the articles cost reduction "objectives").

The last two reports have focused on the RS-25 engine, last time the GAO was unhappy because an engine cost Nasa $100 million and Nasa had just granted a development contract to reduce the cost of the engine.

However if you took the headline cost of the contract and split it over planned engines it was greater than the desired cost savings. Nasa response was development costs don't count.

Congress reviews GAO reports and decides to give SLS more money.

Similar to most navies.

Engineering's workload won't really change, they'll do certain types of maintenance.

Most navies don't have command staff on the bridge full time. There would be a watch officer who is fairly junior learning how to operate the ship so the down time is an opportunity for them to grow and learn.

Most navies seperate the captain and first officer, with the first officer involved in running the ship and the captain running the big picture.

So you would expect the first officer to spend the time checking on every department to ensure they are up to standard.

That would mean department heads would be running drills or bringing equipment down for maintenance so its ready.

The captain would likely be planning and thinking through the encounter.

For any free time senior officers have there is probably a mountain of reports (personnel, ship, intelligence, etc..) to read and keep tabs on.

The other person was just wrong.

Large scale Hydrogen generation isn't generated in a fossil free way, Hydrogen can be generated is a green way but the infrastructure isn't there to support SLS.

Hydrogen is high ISP (miles per gallon) by rubbish thrust (engine torque).

This means SLS only works with Solid Rocket Boosters, these are highly toxic and release green house contributing material into the upper atmosphere. I suspect you would find Falcon 9/Starship are less polluting as a result.

Lastly the person implies SLS could be fueled by space sources (e.g. the moon).

SLS is a 2.5 stage rocket, the boosters are ditched in Earths Atmosphere and the first stage ditched at the edge of space. The current second stage doesn't quite make low earth orbit.

So someone would have to mine materials on the moon and ship them back. This would be far more expensive than producing hydrogen on Earth.

Hydrogen on the moon makes sense if your in lunar orbit, not from Earth.

Do not mix tabs and spaces.

Its impossible to automate checking that tabs were only used for indentation and spacing for precise alignment. So you then take on a burden of manually checking

You end up with the issue where someone didn't realise and space idented or anouther person used tabs for precise alignment and people forget to check the whitespace characters in review and it ends up going inconsistent and becoming a huge pile of technical debt to fix.

Use only one, you can automate enforcement and ensure the code renders consistency.

Years ago there was no way to share IDE settings between developers.

You ended up with some developers choosing a tab width of 2 spaces, some choosing 4 spaces and as there was no linting enforcement some people using 2-4 spaces depending on their IDE settings.

This resulted in an unreadable mess as stuff was idented to all sorts of random levels.

It doesn't matter if you use tabs or spaces as long as only one type is consistently used within a project.

Spaces tends to win because inevitably there are times you need to use spaces and so its difficult to ensure a project only uses tabs for identation.

IDE's support converting tabs into spaces based on tab width and code formatting will ensure correct indentation. You can now have centralised IDE settings so everyone gets the same setup.

Honestly 99% of people don't care about formatting (they only care when consistency isn't enforced and code is hard to read), there is always one person who wants a 60 charracter line width or only tabs or double new lined parathensis. Who then sucks up huge amounts of the team time arguing their thing is a must while they code in emacs, unlike the rest of the team using an actual ide.

I am actually arguing for a stable ABI.

The few times I have had to compile out of tree drivers for the linux kernel its usually failed because the ABI has changed.

Each time I have looked into it, I found code churn, e.g. changing an enum to a char (or the other way) or messing with the parameter order.

If I was empire of the world, the linux kernel would be built using conan.io, with device trees pulling down drivers as dependencies.

The Linux ABI Headers would move out into their own seperately managed project. Which is released and managed at its own rate. Subsystem maintainers would have to raise pull requests to change the ABI and changing a parameter from enum to char because you prefer chars wouldn't be good enough.

Each subsystem would be its own "project" and with a logical repository structure (e.g. intel and amd gpu drivers don't share code so why would they be in the same repo?) And built against the appropriate ABI version with each repository released at its own rate.

Unsupported drivers would then be forked into their own repositories. This simplifies depreciation since its external to the supported drivers and doesn't need to be refactored or maintained. If distributions can build them and want to include the driver they can.

Linus job would be to maintain the core kernel, device trees and ABI projects and provide a bill of materials for a selection of linux kernel/abi/drivers version which are supported.

Lastly since every driver is a descrete buildable component, it would make it far easier for distributions to check if the driver is compatible (e.g. change a dependency version and build) with the kernel ABI they are using and provide new drivers with the build.

None of this will ever happen. C/C++ developers loath dependency management and people can ve stringly attached to mono repos for some reason.

The linux kernel is very old school in how it is run and originally a big part of the DevSecOps movement was removing a lot of manual overhead.

Moving on to something like Gitea (codeberg) would give you a better diff view and is quicker/easier than posting a patch to a mailing list.

The branching model of the kernel is something people write up on paper that looks great (much like Gitflow) but is really time consuming to manage. Moving to feature branch workflow and creating a release branches as part of the release process allows a ton of things to be automated and simplified.

Similarly file systems aren't really device specific, so you could build system tests for them for benchmarking and standard use cases.

Setting up a CI to perform smoke testing and linting, is fairly standard.

Its really easy to setup a CI to trigger when a new branch/pr is created/updated, this means review becomes reduced to checking business logic which makes reviews really quick and easy.

Similarly moving on to a decent issue tracker, Jira's support for Epic's/stories/tasks/capabilities and its linking ability is a huge simplifier for long term planning.

You can do things like define OKR's and then attach Epics to them and Stories/tasks to epics which lets you track progress to goals.

You can use issues the way the linux community currently uses mailing lists.

Combined with a Kanban board for tracking, progress of tickets. You remove a ton of pain.

Although open source issue trackers are missing the key productivity enablers of Jira, which makes these improvements hard to realise.

The issue is people, the linux kernel maintainers have been working one way for decades. Getting them to adopt new tools will be heavily resisted, same with changing how they work.

Its like everyone outside, knows a breaking the ABI definition from the sub system implementation would create a far more stable ABI which would solve a bunch of issues and allow change when needed, except no one in the kernel will entertain the idea.

During the pandemic I had some unoccupied python graduates I wanted to teach data engineering to.

Initially I had them implement REST wrappers around Apache OpenNLP and SpaCy and then compare the results of random data sets (project Gutenberg, sharepoint, etc..).

I ended up stealing a grad data scientist because we couldn't find a difference (while there was a difference in confidence, the actual matches were identical).

SpaCy required 1vCPU and 12GiB of RAM to produce the same result as OpenNLP that was running on 0.5 vCPU and 4.5 GiB of RAM.

2 grads were assigned a Spring Boot/Camel/OpenNLP stack and 2 a Spacy/Flask application. It took both groups 4 weeks to get a working result.

The team slowly acquired lockdown staff so I introduced Minio/RabbitMQ/Nifi/Hadoop/Express/React and then different file types (not raw UTF-8, but what about doc, pdf, etc..) for NLP pipelines. They built a fairly complex NLP processing system with a data exploration UI.

I figured I had a group to help me figure out Python best approach in the space, but Python limitations just lead to stuff like needing a Kubernetes volume to host data.

Conversely none of the data scientists we acquired were willing to code in anything but Python.

I tried arguing in my company of the time there was a huge unsolved bit of market there (e.g. MLOP's)

Alas unless you can show profit on the first customer no business would invest. Which is why I am trying to start a business.

This is why Java rocks with ETL, the language is built to access files via input/output streams.

It means you don't need to download a local copy of a file, you can drop it into a data lake (S3, HDFS, etc..) and pass around a URI reference.

Considering the size of Large Language Models I really am surprised at how poor streaming is handled within Python.

The issue is the state pension was raided in the 1980's to allow for reduced taxes and so now an increasingly large chunk of the national budget goes on state pensions.

If you factor in the majority of the NHS budget goes on geriatric care or elder social care you end up with more than 50% of the annual budget is to support the elderly.

Its not sustainable.

I think the easiest approach would be to means test the state pension by using tax thresholds. If your household income (excluding state pension) exceeds the free tax threshold (£12,500) then you don't qualify for a state pension.

Ideally we would increase minimum wage, the tax thresholds and state pension to align with the living wage foundation recommendations.

From a business perspective, you need to assess the impact of the regulation on your profitabiity and then consider if investing business funds elsewhere would lead to greater profitability.

WhatsApp have a single product and have market dominance due to first mover advantage (e.g. everyone is on WhatsApp, so everyone uses WhatsApp). Due to the nature of the business pulling out doesn't make sense unless they only have a limited development team and having them work on UK legal requirements prevents them working on EU requirements, however they are largely similar... (e.g. opportunity cost).

Many 'BigTech' products were developed by small teams, the biggest barrier for entering the market isn't technology but user adoption (KBin, Mastodon, PeerTube & Lemmy demonstrate this, all were developed by 1-2 people in their spare time).

So a 'BigTech' company exiting would be giving up the market in that country and any profit and creating an opportunity for a new small company to grow and eventually compete with them. For example if Facebook pulled out, I'm guessing people would switch to NextDoor, if Twitter quit people would move to Mastodon, etc..)

The US Technology sector is filled with Libretarians who get upset at the idea of regulation. I'm not sure Shareholders/Venture Capitalists would react well to them making decisions for those reasons.

I think they mean Woolworths.

Fun story...

Plymouth's Woolworths was the largest in the country with the largest revenue (and profit). For 5 years it had no regional manager because no one from head office wanted to trek that far. As a result it was completely ignored and not refitted or supported.

During that period head office made us all do an employee survey. One of the questions was "Do you think Woolworths will still be here in 5 years". The store manager got shouted at because our store of 100 all said "no".

After much consideration we were all made to redo the questionaire, this time without the question.

Just as I left a regional manager was appointed who dictated floor layout changes. Being months from finishing university I told him his changes defied how shoppers acted and would cost the store thousands. He told me I was just a shop worker and knew nothing.

A week later on daily revenue of £10k-£20k (Saturday was £100k) the store was down £50k for the week. Apparently he forced more changes and it got worse.

Everyone I talk to in retail has similar stories, all of it is terribly managed.

I think its a self burn.

Person has never been in a relationship and so has no ex to photograph

Maven has unit and integration test phases and there are a multitude of plugins designed to hook into those phases but there are constraints by design.

Trying to hook everything into the build management system is a source of technical debt, your using a tool for something it wasn't designed.

I would look at what makes sense within the build management system and what makes sense in a CI pipeline.

CI tools have different DSL and usually provide a means to manage environments. Certain integration and system level tests are best performed there.

For instance I keep system tests as a seperate managed project. The project can be executed from developer machines for local builds but I also create a small build pipeline to build the project, deploy it and run the system tests against it triggered by pull requests.

This is why I say the build management system doesn't really change, because you should treat everything as descrete standalone components.

The Parent POM gets updates once every six months, the basic build verification CI pipeline only changes to the latest language release, etc..

Projects which try to embed gitflow into a pom or integrate CD into the gradle file are the unbuildable messes I get asked to fix.