imtringued

This is something I noticed as well.

Because humans were, loosely speaking, careful about not making egregious security mistakes, most security vulnerabilities turned out to be either harmless or the result of a programming language allowing the type of exploit to begin with.

But now we have code from non-people ordered by people who both don't care about security at all.

That means you will get maximally bad security outcomes which in turn will make governments consider regulating the software development industry. They are speed running their own demise.

I am wondering if these managers and CEOs even understand what their company's product is and that this lack of understanding is what causes them to become obsessed with things only a manager does. Which is ironic in the face of the accusations that developers are against AI because they just want to keep their jobs. It's the managers who want to live out their management fantasy.

I can choose a weak LLM to disprove your entire comment. Next time come up with something that can't be debunked in two seconds.

His top customer is skunk-ape.

You're assuming that management cares about having good software more than it cares about replacing developers with a machine.

Every single bullet point is an eldritch horror story.

Correct, the problem isn't that SpaceX no longer needs NASA, it's that SpaceX has failed to achieve any meaningful development milestones with Starship so far and the competition has either had some setbacks or isn't delivering either.

Crew dragon being retired is only a problem in so far that Starship isn't ready. It's really strange to somehow spin "SpaceX is doing something stupid that hurts customers" into "SpaceX is too competent for its customers".

As far as we know, Starship should fix the limited payload issues of Falcon 9 so why would anyone ever have to worry about Starship only launching Starlink satellites?

It's also weird how shutting down Falcon 9 and crew dragon means that SLS and Orion cannot be canceled anymore even if congress (the boogeyman) agreed.

Make this make sense.

What?

Special casing your domains to be assumed "secure" is exactly how you build vulnerabilities directly into your software.

It's an inevitable result.

Developers aren't aware because they assume a security model where the special casing is disabled.

This is AI generated so it could be wrong:

    const std = @import("std");
    
    fn performTasks(io: std.Io) !void {
        var group: std.Io.Group = .init;
        errdefer group.cancel(io);

        // Launch concurrent background jobs
        try group.async(io, simulateWorker, .{ io, 1 });
        try group.async(io, simulateWorker, .{ io, 2 });

        // Wait for all group tasks to complete
        try group.await(io);
    }
    
    fn simulateWorker(io: std.Io, id: usize) void {
        std.log.info("Worker {d} started...", .{id});
        
        // Any blocking operation (like sleeping) routes through 'io'
        // Under the hood, this will either block an OS thread or yield an event loop stack.
        io.sleep(.fromSeconds(1), .awake) catch {};
        
        std.log.info("Worker {d} finished!", .{id});
    }
    
    pub fn main() !void {
        var gpa_alloc = std.heap.GeneralPurposeAllocator(.{}){};
        defer _ = gpa_alloc.deinit();
        const allocator = gpa_alloc.allocator();
    
        // Initialize the Threaded I/O backend
        var threaded = std.Io.Threaded.init(allocator, .{
            .async_limit = std.Io.Limit.limited(4), // Max concurrent tasks in the pool
        });
        defer threaded.deinit();
        
        // Extract the generic I/O interface pointer
        const io = threaded.io();

        std.log.info("Running on Threaded backend:", .{});
        try performTasks(io);
    }


    pub fn main() !void {
        var gpa_alloc = std.heap.GeneralPurposeAllocator(.{}){};
        defer _ = gpa_alloc.deinit();
        const allocator = gpa_alloc.allocator();

        // Initialize the Evented (non-blocking) backend
        var evented: std.Io.Evented = undefined;
        try evented.init(allocator, .{
            .thread_limit = 4, // Worker threads running the event loop
        });
        defer evented.deinit();
    
        // Extract the exact same generic interface
        const io = evented.io();

        std.log.info("Running on Evented backend:", .{});
        try performTasks(io);
    }

std.Io.Threaded and std.Io.Evented are two types of IO backends. std.Io.Threaded uses blocking IO primitives and Evented uses asynchronous IO primitives. Switching between backends is done via dynamic dispatch, the used backend is passed in via an explicit function parameter.

The only real question you should have is, how does the "non-blocking" case work when the interface is still a synchronous call? Well, the answer is quite boring... You just call into the scheduler and it runs the other task inside the blocked operation.

I was promised hidden magic and implicit logic! Now I want a refund!

They have a strong incentive to make themselves look less incompetent retroactively.

If they claim their AI is too powerful to contain, they get to both pretend they are among the best AI labs and that the previous incidents weren't their fault, no, they just proved how good their models were.

What's the point in putting the vibe back in if you're implementing a specific software development process to avoid the vibe?

You're talking about your own free rider attitude, if you haven't noticed.

You say you want X but you do Y.

But then you say you don't want X, you want someone to magically make Y as good as X.

That type of wishful thinking is all the rage in politics.

Software slop made hardware slop viable.

You mean you will never get a promotion for rejecting other people's bad pull requests.

Correct. Everything will disappear, even hardware jobs and the trades but the people responsible with the automation jobs (software developers) will be the last to go.