entrox

And that is a good thing. What the human operator did was completely irresponsible and malicious, paying a small bill is hopefully educational and will correct their behavior going forward.

Having agents like this interacting with human communities is a scourge that must be prevented. With every passing day my longing for a Butlerian Jihad grows firmer.

I tend to agree with OP. In my opinion conscious machines are not something that we should allow to exist. If they do, they are not human and must never be treated as such.

I am not even slightly religious, but they would be abomination.

In this case you could even replace "LLM" with "C compiler" and it would change nothing.

Look, I still got my physical copy of Michael Abrash's Graphics Programming Black Book with its genius content about hand-optimizing cycle count on 486 and Pentium processors, beating compilers at that time.

It was an absolute artform, but completely obsolete by today.

Almost a decade ago, I moved my career into the management track. I am a director by now and have two more management levels between myself and individual contributors.

I can strongly relate to what you‘re writing, because I share that same sentiment often in my daily (non-AI) work. In fact, coming from that background, the switch from coding to working with agents feels eerily similar to moving into management. You encounter the same challenges minus the „human people and emotions“ part: having to explain properly, the agents doing something different than what you intended, feeling detached from the actual work, only focusing on the bigger picture and so on

To me it feels very natural, it is what I do every day. But then again, I made that choice and it wasn‘t forced on me. So I understand frustration.

Well, not yet. It's a matter of organization, regulation and litigation.

I was thinking along the lines of concepts that already exist, such as the private copying levy [0]. It basically forces a blanket tax on a certain class of products, which then gets redistributed to members of a collecting society such as GEMA [1].

This way, you would force LLM model builders to effectively pay a tax by law. Since these models do not work at all without underlying content, make it proportionate. Let's say 50-70% to make it fair.

[0] https://en.wikipedia.org/wiki/Private_copying_levy

[1] https://en.wikipedia.org/wiki/GEMA_(German_organization)

Of course they want to get paid for it.

So should the original authors, no? That is, getting a share of that payment.

Something akin to the German GEMA could work, an entity that levies a usage fee on behalf of all copyright holders and re-distributes to its members, but on a global scale.

Does it have to be? The etymology of the word „abstraction“ is „to draw away“. I think it‘s relevant to consider just how far away you want to go.

If I‘m purely focused on the general outcome as written in a requirement or specification document, I‘d consider everything below that as „abstracted away“.

For example, this weekend I built my own MCP server for some services I‘m hosting on my personal server (*arr, Jellyfin, …) to be integrated with claude.ai. I‘ve written down all the things I want it to do, the environment it has to work in and let Claude go.

Not once have I looked at the code. And quite frankly, I don‘t care. As long as it fulfills my general requirements, it can write Python one time and TypeScript the other time should I choose to regenerate from that document. It might behave slightly differently but that is ok to a degree.

From my perspective, that is an abstraction. Deterministic? No, but it also doesn‘t have to be.

It is quite frankly ridiculous that you need to be in the "in-group" to get things like this resolved and it is not the first time this has been reported, be it Google or Meta or any other big tech corpo.

These players MUST be regulated or treated like utilities; hoping the EU will ratchet up the pressure even more.

Are these examples supposed to be bad? I think the world would be in a better place.

It used to be that you had to have a strong understanding of the underlying machine in order to create software that actually worked.

Things like cycle times of instructions, pipeline behavior, registers and so on. You had to, because compilers weren‘t good enough. Then they caught up.

You used to manage every byte of memory, utilized every piece of underlying machinery like the different chips, DMA transfers and so on, because that‘s what you had to do. Now it‘s all abstracted away.

These fundamentals are still there, but 99,9% of developers neither care nor bother with them. They don’t have to, unless they are writing a compiler or kernel, or just because it‘s fun.

I think what you‘re describing is also going to go away in the future. Still there, but most developers are going to move up one level of abstraction.

Having worked in a very large company for the past two decades now, one of the best career advices I ever got is about how you measure if you are a „good employee“.

It is very simple: you are a good employee if your boss(es) think you are.

That’s it. Nothing else matters in terms of career advancement or retainment.

Elderly care will always have more demand than supply.

Given how easy it was to get banned, the :tenbux: were almost like a subscription.

No, you misunderstood. It is not about their output, it almost never is.

Most of the times, the business decision has already been made long before McK is hired. It’s all about legitimizing that decision and making it happen.

You can also wield them as a weapon against internal competitors or opponents. Look up how they were used to kill off Cariad for example.

I believe you misunderstood the point of my comment, or rather I didn't make it clear enough. The quotes I quickly picked out feel like they represent a majority opinion on HN, namely that this is progress and disruption. I don't share that opinion.

My own gut feeling is that this sentiment comes out of a position of superiority and a definite lack of empathy. It is software engineers building the technology that is leading to job loss, sloppification of everything as well as second order effects like storage and RAM prices soaring because of the hype.

As such, I find it ironic to complain about being replaced. After all, your profession is the one responsible for all of this, so now please take a look in the mirror and take responsibility for the actions of the industry you choose to work in.

Personally, I think the current trajectory of AI is an overall net negative to society. I sincerely hope it all comes crashing down in another AI winter, but we'll see.

I do not disagree, in fact I'm feeling more and more Butlerian with every passing day. However, it is undeniable that a transformation is taking place -- just not necessarily to the better.

Why is it bizarre? It is inevitable. After all, AI has not ruined creative professions, it merely disrupted and transformed them. And yes, I fully understand my whole comment here being snarky, but please bear with me.

Let's rewind 4 years to this HN article titled "The AI Art Apocalypse": https://news.ycombinator.com/item?id=32486133 and read some of the comments.

Actually all progress will definitely will have a huge impact on a lot of lives—otherwise it is not progress. By definition it will impact many, by displacing those who were doing it the old way by doing it better and faster. The trouble is when people hold back progress just to prevent the impact. No one should be disagreeing that the impact shouldn't be prevented, but it should not be at the cost of progress.

Now it's the software engineers turn to not hold back progress.

Or this one: https://news.ycombinator.com/item?id=34541693

[...] At the same time, a part of me feels art has no place being motivated by money anyway. Perhaps this change will restore the balance. Artists will need to get real jobs again like the rest of us and fund their art as a side project.

Replace "Artists" with "Coders" and imagine a plumber writing that comment.

Maybe this one: https://news.ycombinator.com/item?id=34856326

[...] Artists will still exist, but most likely as hybrid 3d-modellers, AI modelers (Not full programmers, but able to fine-tune models with online guides and setups, can read basic python), and storytellers (like manga artists). It'll be a higher-pay, higher-prestige, higher-skill-requirement job than before. And all those artists who devoted their lives to draw better, find this to be an incredibly brutal adjustment.

Again, replace "Artists" with coders and fill in the replacement.

So, please get in line and adapt. And stop clinging to your "great intellectually challenging job" because you are holding back progress. It can't be that challenging if it can be handled by a machine anyway.

I feel different: the last line is very important in this context, since it communicates the underlying thoughts and values of the poster.

Asking for "amazing" open source projects in this case is not asking out of genuine curiosity or want for debate, it is a rhetorical question asked out of frustration at the general trajectory of AI and who profits off of it -- namely the boot-wearers.

But now the meaning is different: you went from a potential interview to a guaranteed one.

They've even got their own slogan: "you're probably just not prompting it properly"

That's the same energy as telling other professions to "just learn to code, bro" once they are displaced by AI.

But I guess it doesn't feel nice once the shoe is on the other foot, though. If nobody values the quality of human art, why should anybody value the quality of human code?

"I sound seven percent more like Commander Shepard than any other bootleg LLM copy!"

I agree, but why not both?

How is this my fault as customer? This a predatory practice in tech.

I work in automotive, the hoops you have to jump through in order to push a SW update are enormous. One of the first rules is: if the owner of the vehicle does not consent to an OTA update, you're out of luck.

The industry is obviously unable to self-regulate, so it is time for an external regulator, e.g. the EU, to jump in and mandate that SW updates cannot be applied without explicit consent and an explicit explanation of what is being changed. Of course, security updates must be maintained separately from feature updates like this.

As a consumer, I always want the latter, rarely do I want the former. My device, my choice.

I likely did not communicate clearly enough: it is tricky because of organizational reasons, not technical. There are many trade-offs that have to be made and it involves different business units with their own targets and incentives.

To take a few examples from the article with likely causes (note I don't work for BMW, so this is pure speculation based on my own experience):

BMW has over-engineered the diagnostic procedure to such a level that even their own technicians often do not know the correct replacement process.

The ECU, diagnostic procedures and service methods are being developed by a different org-units. One is engineering, which works towards their own development use cases. They might develop the on-board diagnostic interfaces. The service unit develops their own tester and have to develop their own procedures.

Engineering is usually late with providing real hardware & software samples, let alone a fully integrated car. The service unit might only get a working test car very late in the process and discover that the procedure is super complicated. By that point the car development is already too far along for major changes. Remember that most components have been specified and awarded to suppliers years ago by this point.

And it gets worse: the original iBMUCP module, which integrates the pyrofuse, contactors, BMS and internal copper-bonded circuitry, is fully welded shut. There are no screws, no service openings, and it is not designed to be opened, even though the pyrofuse and contactors are technically replaceable components.

Engineering is not concerned with these issues, it's usually the service unit which needs to bring in maintenance requirements. A judgement call is being made whether an assembly that you source as a single part needs to be split up further. For example, if you split it up further, you now have more parts to manage. You need to provide logistics and must allocate space in your spare parts warehouses for these new parts.

That usually makes sense for expensive components. Here's another fact: the manufacturer allocates a warranty & goodwill budget for each car line, because the manufacturer has to pay dealers for these repairs if it falls into the warranty period or is judged to fall under good will. It's usually not in the interest of the manufacturer to have expensive repairs because of that.

It might also be that the repair is being deemed to dangerous, because it is a high-voltage component. Opening it up and tinkering with it might increase the risk of an electrical fire in the battery. It might be that this risk was judged to be higher than the repair cost.

Additionally, the procedure requires flashing the entire vehicle both before and after the replacement, which adds several hours to the process and increases risk of bricked components which can increase the recovery cost by factor 10x.

No service unit wants these long flashing times, because it blocks a repair bay in the workshop. But it's usually because the EE integration has been developed in this way. It might need coding, calibration or just bringing up everything to the latest release.

Vehicle SW is super regulated, you need to fulfill a staggering amount of regulations. Look up UNECE-R156 SUMS as an example. It might be that the new parts comes with a newer SW version, which has only been verified and approved in combination with newer SW in the other components. This would require flashing ancillary ECUs as well even if they have not been changed to ensure release compliance.

Even after we managed to open the unit and access everything inside, we discovered that the Infineon TC375 MCU is fully locked.

Look up UNECE-R155. Things like these are mandated, if not directly in the regulation then indirectly by making the manufacturer liable for any modification that somebody did to their car. It is practically required to lock it down.

Just a few points off the top of my head, the comment got too long anyway.

There's no reason to make the process of fixing the issue after a minor incident expensive, extremely convoluted, and very prone to error.

Yes there is. Either nobody is engineering towards that aspect or it is a conscious decision, deliberating between two different buckets: bill-of-material cost per unit and estimated impact on your warranty & goodwill budget. Whatever is deemed to be cheaper will win.

Source: I work at an automotive OEM and one of my first projects almost two decades ago was how to anchor after-sales requirements into the engineering process. For example, we did things like introducing special geometry into the CAD models representing the space that needs to be left free so a mechanic can fit his hands with a tool inside. These would then be considered in the packaging process. If you consider these are two completely different organizations, it becomes a very tricky problem to solve.

Yes, it works basically everywhere you'd interact with a local file or directory.

For example, you open a remote dired buffer with C-x C-f /ssh:host:/dir/. Afterwards, opening a file or navigating to a directory will open it remotely as well. You can also use project functions or magit seamlessly. I have plenty of bookmarks remotely etc.

Fundamentally, you just prepend "/ssh:[user@]host:" to any path or file operation and things will magically Just Work (tm).

I just haven't found Emacs to be particularly productive over SSH. IMO it works best on a local machine, there's just too much in the GUI which isn't as workable over terminal. Font rendering, images, clickable text links all take a hit. None are really deal breakers, but Emacs TUI just kind of feels like an afterthought. X11 over SSH doesn't feel responsive to me.

But that's what tramp is for, it works nicely and is surprisingly well integrated into the rest of Emacs. The only obvious downside is initial performance, but that can be worked around by tweaking SSH settings to keep connections open.

Another hack I use is to initiate a connection from remote to my local Emacs instance. The use case is ssh'ing into a remote shell, typing "remote-emacs <file-xyz>" and having that open the file on my local machine.

I did that by creating a script that gets my local IP from $SSH_CONNECTION, uses that to ssh into my local machine and executes "emacsclient -n /ssh:$HOSTNAME:$FILEPATH" which then in turn opens the remote file using tramp. Pretty useful.

FreeCAD is definitely not something you can just pick up, but it's pretty intuitive if you're coming from CATIA as the workflow is very similar.

If the system values proportional representation higher than qualification, than I will either abandon my own strive towards excellence or I will actively support changing that system.

I feel the latter option is more likely than abandoning something that is often shaping one's own identity

I very much applaud the effort in trying to push the boundaries, especially on the front of responsiveness and performance. We are typing on machines with mind-boggling resources and yet editors don't feel snappier(tm) at all, so I appreciate optimizing on that dimension.

However, I can't see myself moving away from Emacs. I've been using it for almost a quarter of a century and have seen many editors come and go in that timeframe: BBEdit, Textmate, Sublime Text, Atom and so on. The current hotness is VS Code, but I personally believe that will be abandoned at some point as well.

It would be great if some of the learnings of Zed can be backported to Emacs, however unlikely that is due to the amount of old cruft there.