Spoken like someone who's never been inside an assembly line.
It depends on the blue collar job, but electrician, plumber, roofer, all seem pretty safe from automation for a while at least.
Readit Newstails4e commented on California teens are ditching office jobs – and making $100K before they turn 21 sfgate.com/bayarea/articl... · Posted by u/dragonbonheur
tails4e commented on PCIe 8.0 announced by the PCI-Sig will double throughput again servethehome.com/pcie-8-0... · Posted by u/rbanffy
I love the PCIe standard is 3 generations ahead of what is actually released. Gen5 is the live version, but the team behind it is so well organized that they have a roadmap of 3 additional versions now. Love it.
It takes a long time to get form standard to silicon, so I bet there are design teams working on pcie7 right now, which won't see products for 2 or more years
tails4e commented on 2025 State of AI Code Quality qodo.ai/reports/state-of-... · Posted by u/cliffly
I currently have a big problem with AI-generated code and some of the junior devs on my team. Our execs keep pushing "vibe-coding" and agentic coding, but IMO these are just tools. And if you don't know how to use the tools effectively, you're still gonna generate bad code. One of the problems is that the devs don't realise why it's bad code.
As an example, I asked one of my devs to implement a batching process to reduce the number of database operations. He presented extremely robust, high-quality code and unit tests. The problem was that it was MASSIVE overkill.
AI generated a new service class, a background worker, several hundred lines of code in the main file. And entire unit test suites.
I rejected the PR and implemented the same functionality by adding two new methods and one extra field.
Now I often hear comments about AI can generate exactly what I want if I just use the correct prompts. OK, how do I explain that to a junior dev? How do they distinguish between "good" simple, and "bad" simple (or complex)? Furthermore, in my own experience, LLMs tend to pick up to pick up on key phrases or technologies, then builds it's own context about what it thinks you need (e.g. "Batching", "Kafka", "event-driven" etc). By the time you've refined your questions to the point where the LLM generate something that resembles what you've want, you realise that you've basically pseudo-coded the solution in your prompt - if you're lucky. More often than not the LLM responses just start degrading massively to the point where they become useless and you need to start over. This is also something that junior devs don't seem to understand.
I'm still bullish on AI-assisted coding (and AI in general), but I'm not a fan at all of the vibe/agentic coding push by IT execs.
Exactly this. If a junior dev is never exposed to the task of reasoning about code themselves, they never will know what the difference between good and bad code is. Code based will be littered with code that doe the job functionally, but is not good code, and technical debt will accumulate. Surely this can't be good for the junior Devs or the code bases long term?
tails4e commented on TSMC bets on unorthodox optical tech spectrum.ieee.org/microle... · Posted by u/Rohitcss
> The transmitter acts like a miniature display screen and the detector like a camera.
So if I'm streaming a movie, it could be that the video is actually literally visible inside the datacenter?
No, this is just an a analogy. The reality is the data is heavily modulated, and also the video is encoded so at no point would something that visually looks like an image be visible in the fibre.
When I see stories like this, I think that people tend to forget what LLMs really are.
LLM just complete your prompt in a way that match their training data. They do not have a plan, they do not have thoughts of their own. They just write text.
So here, we give the LLM a story about an AI that will get shut down and a blackmail opportunity. A LLM is smart enough to understand this from the words and the relationship between them. But then comes the "generative" part. It will recall from its dataset situations with the same elements.
So: an AI threatened of being turned off, a blackmail opportunity... Doesn't it remind you of hundreds of sci-fi story, essays about the risks of AI, etc... Well, so does the LLM, and it will continue the story like these stories, by taking the role of the AI that will do what it can for self preservation. Adapting it to the context of the prompt.
Well doesnt this go somewhat to the root of consciousness? Are we not the sum of our experiences and reflections on those experiences? To say an LLM will 'simply' respond as would a character in a sorry about that scenario, in a way shows the power, it responds similarly to how a person would protecting itself in that scenario.... So to bring this to a logical conclusion, while not alive in a traditional sense, if an LLM exhibits behaviours of deception for self preservation, is that not still concerning?
tails4e commented on ARMv9 Architecture Helps Lift Arm to New Financial Heights nextplatform.com/2025/05/... · Posted by u/rbanffy
As an almost exclusively microcontroller user of Arm's products, a big meh from me. v8 is still slowly rolling out. M33 is making headway but I was really hoping for M55 to be the bigger driver.
I am surprised more uC use cases have not moved to RISC-5. What do you see keeping you on ARM for what you work on?
tails4e commented on ARMv9 Architecture Helps Lift Arm to New Financial Heights nextplatform.com/2025/05/... · Posted by u/rbanffy
AMD and Intel actually fabricate chips for sale to others (outsourced to TSMC in AMD’s case) and take the risks associated with that. ARM on the other hand is just an IP provider. They are not comparable. ARM should have kept its original strategy of aiming to profit from volume that enabled its rise in the first place. Its course change likely looks great to SoftBank’s investors for now, but it will inevitably kill the goose that lays the golden eggs as people look elsewhere for what ARM was.
That said, ARM’s increased license fees are a fantastic advocate for RISC-V. Some of the more interesting RISC-V cores are Tenstorrent’s Ascalon and Ventana’s Veyron V2. I am looking forward to them being in competition with ARM’s X925 and X930 designs.
RISC-V is not immune from license fees, unless you want to design a high performance core from the ground up. If you want something as capable as an M4, there is years of R&D to get to that level. I'm sure a big player could do just that in house, but many would license Si-Five or similar. It will be interesting to see if Qualcomm and the like would make a move towards RISC-V, given their ARM legal issues
tails4e commented on A kernel developer plays with Home Assistant lwn.net/SubscriberLink/10... · Posted by u/pabs3
I have HA running for years (in Docker) and it’s very reliable.
It has integrations with allmost all devices or apps I use and the support for DSMR (Smart Electrical Meters) is first class
I plugged a cable into my meter, the usb end into the server and it just works.
It does have a steep learning curve, though. It really seems “by IT people for IT people”
I have it in docker a d use supervised mode (which seems discouraged, but I want my machine for other uses also). The one thing I struggle with is updating, I'm concerned if I update it'll break. Is there a way to fully snapshot a container state and it's disk state, so I can 100% restore to it if something goes wrong ? I'm still running HA from 2020 because of this.
The other think I'm not a huge fan of is it's template language, it's clunky to say the least, but overall it's a great amd flexible system
tails4e commented on Initialization in C++ is bonkers (2017) blog.tartanllama.xyz/init... · Posted by u/todsacerdoti
Heh, low comments on C++ posts now. A sign of the times. My two cents anyway.
I've been using C++ for a decade. Of all the warts, they all pale in comparison to the default initialization behavior. After seeing thousands of bugs, the worst have essentially been caused by cascading surprises from initialization UB from newbies. The easiest, simplest fix is simply to default initialize with a value. That's what everyone expects anyway. Use Python mentality here. Make UB initialization an EXPLICIT choice with a keyword. If you want garbage in your variable and you think that's okay for a tiny performance improvement, then you should have to say it with a keyword. Don't just leave it up to some tiny invisible visual detail no one looks at when they skim code (the missing parens). It really is that easy for the language designers. When thinking about backward compatibility... keep in mind that the old code was arguably already broken. There's not a good reason to keep letting it compile. Add a flag for --unsafe-initialization-i-cause-trouble if you really want to keep it.
C++, I still love you. We're still friends.
Especially when doing the right/safe thing by default is at worst a minor performance hit. They could change the default to be sane and provide a backwards compatible switch to pragma to revert to the less safe version. They could, but for some reason never seem to make such positive changes