I preferred it without colour, half of the fun is finding the ships, like a where's wally/waldo
1,006 karma · joined October 25, 2022
2. AI doing production triage work
3. AI code reviews before submittng work to my team to review.
4. The workers that haven't embraced AI assistance work at a slower pace, which bottlenecks teams when you rely on them. This is particularly noticeable when it comes to PRs and there are a (human usual) number of defects requiring more time to fix and/or refactor.
Using AI doesn't mean it has to take your job, it means like an intelligent IDE, it can correct your code and instead of templates (e.g. implement this interface and you get stubs) you have entire classes written.
That reads like a coverup as open discourse would have admitted a mea culpa and apology.
I predict they will close the issue without discussion, citing this PR as the fix, potentially associating the fix with a less guilty looking duplicate ticket.
I'd like to be wrong but this is what other commercial projects do when they are called out on a shady practice.
If you can't beat 'em, join 'em.
AKA an AI consultant. I will add value at every step, and tell you how to run your business more efficiently with AI.
My playbook:
Sack those engineers for whom business already want to let go, just validate their beliefs.
Automate everything else under the guise an AI subscription will save them money (like outsourcing advice).
Then reap the whirlwind and take the opposite position when it rolls around again, hire more workers, have them take over roles that need the human touch.
I suppose write once run anywhere is no longer a goal either.
"It is not a goal to support all CPU architectures currently supported by HotSpot."
This pretty much validates the point of view that VM design is now baggage, as a sandbox it has been flawed, for performance it's been prohibitive, and cross platform portability by virtue of being virtual, was just a convenient byproduct.
AI now handles the portability, sandbox security hasn't changed (cf. docker still has sandbox problems, LLMs have sandbox problems, it's always an ongoing concern) and that just leaves Java, as always, chasing performance.
1. A single Skill finder skill, loaded in the prompt, prevents having to import all the summaries in the prompt the harness would add. Uses git's own search.
2. Private repo, per agent, contains main (production) and draft-<name of skill> branches.
3. Shared repo, like 2, but general access for all group agents.
4. Fallback mode, search the harness for skills using the harness mechanism when a relevant skill cannot be found.
5. Skill audit cron. Identify junk skills / drafts that have never changed / not in any recent sessions history, and categorise monthly for me to decide.
This means it's compatible with existing skill folders, removal of git and the finder skill is non destructive and critically debloats the prompt of skills that aren't used and lazy loads them when needed.
It has to be Doom or Crysis, aren't they the ones people usually ask if it can run?
ASTRA HAS BEEN UTTER SHIT.
It is much more expensive than Sol 5.6 Medium / High and did nothing but write unit tests and junk code, despite having access to the vendor original source, an API, and the full tank specs.
Failure Examples:
* In two instances had the direction of the servos wrong.
* Calculated the maximum extent of the gripper wrong, and the closure, so it didn't grip.
* Code failed to take into account the gripper requires continuous torque when lifting a pair of socks, so couldn't lift.
* Failed to actually start physical testing more than opening and closing the gripper, and that was when I asked about progress.
* Code failed quite spectacularly to calculate camera gimbal extent range correctly.
* Code failed to use the ultrasonic in range to target until I pointed it out, the skill also didn't advise gimbal angle adjustment to correct range overshoot to the wall behind a small object.
The test environment has both an onboard ultrasonic for distance, onboard camera, and a bird eyes view camera (birds eyes only while training).
I've stopped using Astra Low (default) and gone back to Sol 5.6 low/medium/high for the training, it's cheaper and now I'm back to fine tuning, after it had to redo large chunk of the gripper/arm code and prevent unnecessary hard stop code kicking in based on the wrong profiling.
It's cost me around 1000 to 1250 credits (£50), burnt in around 2 hours, looking mostly at recorded video, and photos, and writing bad code based on bad assumptions. I've also burnt through regular Plus 5 hour quota in about 30-45 minutes with it.
"AI hacked my website, and all I got was this lousy t-shirt!"
Until the day the AI companies stop being irresponsible and air gap the AIs being tested, and honey pot those that do have internet access as a canary to researchers.
Llama.cpp is then often a few days behind, which given it's the only inference engine supporting older architectures is quite frustrating.
--- The free rider problem is also a form of market failure... The production of public goods results in positive externalities which are not remunerated. If private organizations do not reap all the benefits of a public good which they have produced, their incentives to produce it voluntarily might be insufficient. ---
The US government has just made the NY Times content a public good, and in doing so, allowed openai to create a private good, for which they will be remunerated instead.
It could be argued that this means the US government has effectively taken profit from one company to fund another, under the guise of helping global competitiveness, and whilst this may be the current M.O. of the Trump administration it means predominantly domestic companies are effectively forced into providing export subsidies for the new industry, and monopolising (or oligopolising?) an incumbent.
I wonder if on this basis Seedance could also be equally legally be allowed to use copyrighted media for its video AI, so effectively they're also pulling the legs out from under the film industry too.
Receiver: socat -u TCP6-LISTEN:1234,reuseaddr STDOUT | zstd -d -c | tar -xpf - -C /destination
Sender: tar -C /source -cf - directory | zstd -T0 -6 -c | socat -u STDIN 'TCP6:[fd42:dead:beef::2]:1234'
-T0 uses all cores. Bump the level above -6 for more compression, drop it for more speed, but if your CPU can't keep up, high levels will actually slow it down. Already compressed data won't see much benefit.
tldr; had Qwen orchestrate, do admin and assist with investigations, builds and debugging when codex was unavailable. Codex had a dedicated test physical machine, and I promoted the driver it created to the actual target (production) machine when it was stable enough. Used syncthing to keep the code synced between the different environments, with Qwen sending me progress updates on Telegram and querying Codex periodically.
Long answer:
1) Ran the concept and investigation past Qwen 3.6, I wanted a card that would fit my spare PCIe 3 X1 socket (faster cards in other sockets). Identified the sm750, and read up on its capabilities.
2) Due to speed and Qwen 3.6's capability, I handed Codex (on high) a whole physical scrap machine / fresh Mint install, with root access and the GPU directly connected and asked it what was needed. Syncthing copied the work folder to my machine desktop for visibility to my main orchestrating Qwen AI. Qwen could also ssh to the Codex owned machine to check progress and send me Telegram messages when any milestones were passed, as well as issues that might need me there.
3) I Identified all the chips on the sm750, whilst it was trying the official older sm750 drivers (attempting to get a HDMI signal) and gave them to it.
4) Used /plan mode to set the first iteration expectations, no DRM/integration into the control panel, modifying a checked out fbdev low level FB to test my magic dither algorithm (this can only be used for test, the integration needs to go elsewhere in the stack typically).
5) Left it a few hours, came back to see colour bars (success!)
6) Asked it to do the basic plumbing for X11, wondered how far I could push the frequencies past the VESA standards, fried the HDMI TV attempting high frequency modes (only realised next day I'd done this after the TV refused to activate that connector)
7) Plugged the card directly into the machine it would be used in, and the actual ultrawide monitor. Resumed the codex session on that machine, when daily limits were hit used Qwen 3.6/3.8 to package up builds, look for solutions to issues I was hitting. At this point the hardware is my "production" system, so effectively I've promoted test to staging.
8) From here I manually iterated with Codex by having it create scripts that would build the module for the current kernel to restart X11 with 1-3 ideas / fixes at a time.
9) In parallel, used Qwen to prep the GitHub project, Codex and Qwen to do research for ideas on how to overclock the chips, feasibility of hacks I wanted investigating
10) Asked Codex and Qwen to identify bugs Vs specs, it found a few in event sequencing, resuming events, wrong bits in packets etc.
11) Switched Codex to Max after the the bugs were fixed because the driver performance was laggy, and recommendations from Qwen and Codex Medium/High for optimisations either caused degradations in some way (e.g. DMA was slower) and asked it to audit and optimise the code. I did this over 3 nights due to credit limits getting hit, again 1 to 3 changes at a time.
12) After I was happy with the quality ran the licencing checks again past Qwen and Codex and set up the project on GitHub, held private until I got workflows working.
The unique bits I did do
- Checked the specs for actual hardware limits, DMA and any acceleration
- A magic dither based on my previous (normally coded) older projects (see GitHub)
- Image width "compression" idea with loss reduction using sharpening and a slight aspect change.
- Optimising DMA size chunking for optimal memory transfer.
- A lot of actual manual testing, including sheer reduction, frame rate testing, and multiple resolution and different monitor tests (and I lost one - the HDMI port no longer works on my old Celcus)
Failed experiments with:
- using the onboard secondary controller to bypass the primary controller limitations
- devising a hack that would use the vertical scan horizontally using monitor rotation
- attempting an 8, not 16/32 bit desktop for higher performance (old school technique).
- investigating non hardware hacks for overclocking the onboard chips.
- fixing a KVM issue, that required multiple physical disconnects and reconnects to replicate, and a significant amount of weekend time.
So yeah, vibe coded, because I'd never have been able to try these ideas in such a short timescale if I hadn't.
One avenue I looked at for a real 2560px width was that the second controller was physically independent and could have different hardware limits of the first controller by virtue of supporting DVI directly (but not being physically connected to another port).
Unfortunately other controller is logical so that was a bust.
The dev on this driver used a combination of local Qwen 3.6 and 3.8 27B for admin and basic work, and extensive Codex 5.6 Sol Max to catch the issues I found and do last stage optimisations / isolate the bugs.
I'll freely admit I relied heavily on AI, my expertise and day job is in other software stacks.
I stand on the back of giants :)
On the same machine I experimented with IOMMU and a lightweight VM to run Nvidia Pascal era GPUs in a VM with 580 drivers, while Nvidia Blackwell on the host uses 590. I vibe coded that too
When exposed via openai compatible endpoints with GPUStack https://github.com/gpustack/gpustack I could use the combined compute power from both generations on a single machine.
That one is VGA so I think the original upstream driver should support it.
I created it because I wanted my Nvidia GPUs to be compute only, and needed a cheap and small display GPU to run X11. I bought this GPU on AliExpress, after learning it had Linux support. It does, but kernel 5.x series and the sm750 driver in modern Linux only supports the older VGA/DVI variants.
Rather than send it back or throw it away, I decided to vibe code a new driver with new features, to make it usable for day to day desktop use. I've a little bit of a background in low level graphics so also added a cool little magic ordered dither (a pretty good one I think!) I devised myself, called "bbdither", and a few hacks to get 2560x1080 at 75hz on a device only officially documented as capable of up to 1920x1200 at 60hz, and PCI-E 1x speed.
Screenshots here: https://github.com/KodeMunkie/sm750hdmifb#screenshots
If you try it out, be careful - read the project disclaimer :)
*Vibe coded, as mentioned in Hackernews comments here https://news.ycombinator.com/item?id=49415282