paserbyp: (Default)
paserbyp ([personal profile] paserbyp) wrote2025-07-21 11:04 am
Entry tags:
paserbyp: (Default)
paserbyp ([personal profile] paserbyp) wrote2025-07-20 12:06 pm
Entry tags:
paserbyp: (Default)
paserbyp ([personal profile] paserbyp) wrote2025-07-20 12:03 pm
Entry tags:
paserbyp: (Default)
paserbyp ([personal profile] paserbyp) wrote2025-07-19 11:20 am
Entry tags:

iOS 26 Leaks

Apple is suing YouTuber Jon Prosser for posting details about iOS 26 on his channel(https://youtu.be/YGI8sZqWEl0?si=V7wapwIhPgcuuV_m) earlier this year, which Apple says he acquired through "brazen and egregious" means.

Leaks are nothing new, but in this case, Apple says Prosser worked with Michael Ramacciotti, a product analyst and video editor at NTFTW, on a "coordinated scheme to break into an Apple development iPhone, steal Apple’s trade secrets, and profit from the theft".

Apple alleges that "Ramacciotti needed money," and Prosser promised "compensation in the form of money or a future job opportunity...in exchange for helping Mr. Prosser to access, obtain, and copy Apple confidential information," according to the lawsuit, filed in California district court.

Ramacciotti was friends with Ethan Lipnik, who worked at Apple on unreleased software designs. During a visit to Lipnik's apartment, Ramacciotti figured out the passcode on the development iPhone. Then, when Lipnik left the house, Ramacciotti broke into the phone, called Prosser on FaceTime, and let him see what was on the phone, Apple says. That information was later included in a video posted to Prosser's YouTube channel.

Ramacciotti allegedly used location tracking to see where Lipnik was and make sure he didn't walk in on Ramacciotti sharing details with Prosser.

"According to forensic evidence, Mr. Ramacciotti called Mr. Prosser before he unlocked the Development iPhone, indicating that Mr. Prosser was involved in the decision to improperly access Apple’s trade secrets," according to Apple's lawsuit.

Lipnik didn't find out about this until others "claimed to have seen Mr. Lipnik’s apartment in a video recording from Mr. Prosser," according to Apple's lawsuit. "Only then did Mr. Ramacciotti send an audio message to Mr. Lipnik detailing the compensation proposed by Mr. Prosser and their plan to acquire Apple information," Apple says.

Apple was alerted to the scheme via an anonymous email on April 4. Lipnik also turned over the audio message from Ramacciotti. But even though Lipnik was allegedly duped, Apple still fired him, in part because his work agreement said he was not supposed to leave the development iPhone unattended.

Prosser started his leaks in January, with recreated renders of the new Camera app. Though the renders weren't entirely accurate, the minimalist approach and circular navigation bar were similar to the final product. In a subsequent April video, Prosser leaked a lot more details about iOS 19, including the liquid glass design, the repositioned search and navigation bars, the updated animation for scrolls, and circular app icons. Almost all of those made it to the final iOS build Apple revealed at WWDC 2025.

"Defendants' unlawful acts, which constitute knowing and intentional trade secret misappropriation, have damaged Apple with respect to its competitors, including by giving them the advantage of knowing more about Apple's software designs and unreleased functionality in advance of their release," Apple says in the lawsuit.

Apple seeks to have the court prevent Ramacciotti and Prosser from disclosing any further trade secrets and pay damages.

Prosser denies any wrongdoing. "For the record: This is not how the situation played out on my end. Luckily have receipts for that. I did not 'plot' to access anyone’s phone. I did not have any passwords. I was unaware of how the information was obtained. Looking forward to speaking with Apple on this," he wrote on X(More details: https://x.com/jon_prosser/status/1946056858474525097).
paserbyp: (Default)
paserbyp ([personal profile] paserbyp) wrote2025-07-17 10:52 am
Entry tags:

Joke of the Week

Tesla's robotaxi service might have had a small launch, but CEO Elon Musk is doing everything possible to ensure it stays in the headlines.

After starting the service at a flat rate of $4.20 per ride, Tesla has hiked the fare to $6.90. While the numbers may have been purely strategic, it is hard to ignore the pop culture references they hint at.

420 likely refers to marijuana, something Musk took a hit of on The Joe Rogan Experience. The new price, though Musk described it as "princely," is a reference to a sex position.

Tesla's awkward humor didn't start here. Earlier this week, the company expanded its robotaxi service area in Austin and used the announcement post as an opportunity to flaunt its NSFW humor. An image of the expanded coverage area resembles male genitalia, and the caption just makes it worse: "Harder, Better, Faster, Stronger."

The automaker didn't dial down its humor after posting the picture. In one post, it said the image just represented the company's logo upside down, while in another, it said, "We're big egg plant fans!"

The official Tesla account also took a jibe at news outlets, asking followers if they think "the media will show our updated [profile] robotaxi geofence in their reporting."

If all of that was not enough, Musk's Grok AI app introduced two new AI companions this week, and they talk to users in a flirty tone. The Grok AI app, which made headlines last week for its antisemitic posts, has now added AI companions that users can interact with in real time.

At launch, Grok AI’s Companions will be available to SuperGrok subscribers ($30 per month), who need to enable the feature from the app's settings. This is just a “soft launch,” and enabling the feature will get much easier in a few days, said xAI owner Elon Musk on Monday.

Based on these developments, it's safe to say most of Musk's companies are being a bit too much this week.

As for Tesla's robotaxi service, it currently operates with a fleet of 10-20 Model Ys in a geofenced area in Austin. The service is expected to expand to Phoenix and San Francisco next, with the paperwork done and approval pending.
anais_pf: (Default)
anais_pf ([personal profile] anais_pf) wrote in [community profile] thefridayfive2025-07-17 01:39 pm

The Friday Five for 18 July 2025

This week's questions were suggested by [livejournal.com profile] bindyree

5, 4, 3, 2, 1 . . .

5. Name five favorite movies.

4. Name four areas of interest you became interested in after you were done with your formal education.

3. Name three things you would change about this world.

2. Name two of your favorite childhood toys.

1. Name one person you could be handcuffed to for a full day.

Copy and paste to your own journal, then reply to this post with a link to your answers. If your journal is private or friends-only, you can post your full answers in the comments below.
paserbyp: (Default)
paserbyp ([personal profile] paserbyp) wrote2025-07-16 09:17 am
Entry tags:

DevOps

Despite radical shifts in technology, infrastructure automation has remained largely unchanged. Sure, it’s evolved — from on-prem configurations to cloud and containers — with tools like Terraform and OpenTofu. But the basic premise of declarative configuration management has been around since the 1990s.

“While the tech landscape has changed, the way we think about building automation has not,” says Adam Jacob, CEO and co-founder at System Initiative. “It’s had an incredible run, but we’ve taken that idea as far as it can go.”

Infrastructure as code (IaC) isn’t wrong, but it’s struggling to keep pace with multicloud and scaled devops collaboration. Tools like Terraform rarely offer a one-size-fits-all approach, making configs hard to version and maintain.

“The traditional Terraform or OpenTofu model is very declarative,” says Ryan Ryke, CEO of Cloud Life. “You think, ‘I’m going to build my castle!’ But on Day Two, your castle is falling apart because some developer went in and made some changes.”

At the end of the day, IaC is still just static config files sitting in GitHub repositories that either get stale, or must be regularly reviewed, tested, and updated, becoming a maintenance burden at scale. And because environments always change, mismatches between configs and actual infrastructure are a constant worry.

“Paradigm shift” is a phrase that shouldn’t be used lightly — but that’s the promise of System Initiative. “System Initiative comes closest to a single pane of glass I’ve seen,” says Neil Hanlon, founder and infrastructure lead at Rocky Linux. “Instead of cutting you when you break through, it flexes with you.”

As it stands today, implementing infrastructure as code typically involves a learning curve. “You have to understand all of the technology before you even think about how you can automate it,” says System Initiative’s Jacob.

Engineers typically use tools like Terraform, Pulumi, AWS CloudFormation, or Azure Resource Manager to define and manage infrastructure, versioning configurations in Git alongside application code. But unlike application code, small changes in infrastructure config can ripple across teams — breaking deployments, introducing regressions, and slowing collaboration.

“Configuration programming is worse than application programming, because, if you get it wrong, by definition it doesn’t work,” says Jacob. “You wind up with big, long-running conversations with yourself, the machine, and team members where you’re just trying to figure out how to make it all work.”

Ryke agrees that IaC often leads to toil. “What ends up happening is you spend a lot of time updating Terraform for the sake of updating Terraform,” he says. “We need some sort of tool to rule them all.”

According to Jacob, the deeper problem is that the industry hasn’t treated infrastructure automation as its own domain. Architects have AutoCAD. Game developers have Unity. But devops lacks a comparable standard.

System Initiative aims to change that, as an engine for engineers to build and maintain infrastructure as a living model. “Once you have that engine, you worry less about how to put together the low-level pieces, and more about how to interact with the engine.”

System Initiative turns traditional devops on its head. It translates what would normally be infrastructure configuration code into data, creating digital twins that model the infrastructure. Actions like restarting servers or running complex deployments are expressed as functions, then chained together in a dynamic, graphical UI. A living diagram of your infrastructure refreshes with your changes.

Digital twins allow the system to automatically infer workflows and changes of state. “We’re modeling the world as it is,” says Jacob. For example, when you connect a Docker container to a new Amazon Elastic Container Service instance, System Initiative recognizes the relationship and updates the model accordingly.

Developers can turn workflows — like deploying a container on AWS — into reusable models with just a few clicks, improving speed. The GUI-driven platform auto-generates API calls to cloud infrastructure under the hood.

Infrastructure varies widely by company, with bespoke needs for security, compliance, and deployment. An abstraction like System Initiative could embrace this flexibility while bringing uniformity to how infrastructure is modeled and operated across clouds.

The multicloud implications are especially intriguing, given the rise in adoption of multiple clouds and the scarcity of strong cross-cloud management tools. A visual model of the environment makes it easier for devops teams to collaborate based on a shared understanding, says Jacob — removing bottlenecks, speeding feedback loops, and accelerating time to value.

One System Initiative user is the Rocky Linux project, maker of a free replacement for CentOS, which shifted to CentOS Stream (upstream from Red Hat Enterprise Linux) in late 2020. They’re using System Initiative to build new infrastructure for Rocky Linux’s MirrorManager, a service every Rocky installation uses to find geographically close package mirrors.

Rocky Linux’s community engineers were previously using Terraform, Ansible, and other tools to manage infrastructure piecemeal. But this approach lacked extensibility and posed a high barrier to anyone without deep familiarity. “It made it very difficult to allow other teams to own their applications,” says founder and infrastructure lead Hanlon.

Though still mid-adoption, they’re already seeing collaboration wins. “System Initiative represents a really unique answer to problems faced by open-source organizations like ours, which have fairly decentralized leadership and organization, but where oversight is crucial,” Hanlon says.

Hanlon views System Initiative as a huge force multiplier. “Having a centralized location to manage, inspect, and mutate our infrastructure across any number of clouds or services is an incredibly powerful tool,” he says. “System Initiative will allow our security, infrastructure, and release teams to sleep a bit easier.”

Hanlon especially values how infrastructure is documented as a living diagram, which is malleable to changes and queryable for historical context. For this reason, and others, he believes System Initiative represents the future of devops.

Cloud Life, another System Initiative user, is a cloud consultancy supporting 20 to 30 clients with AWS migrations and IaC. With work highly tailored to each client, they’ve spent years hacking Terraform modules to meet specific project constraints.

“There was never a one-size-fits-all module,” says CEO Ryke. “You could spend a lot of time trying to get everything into a single module, but it was never exactly what we needed for the next customer.”

Terraform adoption has been messy, says Ryke — from public forks to proprietary private modules. Some clients even embed Terraform within source code, requiring hours of updates for small changes.

“Then, you need tooling, and pipelines, and now, the Terraform ecosystem is enormous,” he says. “All to replace a five-minute click if I went into the console.” He’s had enough — battling version changes, back-and-forth with clients, and high project bids for devops maintenance no one wants to pay for. “It’s infuriating as a business owner.”

“The paradigm shift is that System Initiative manages the real world, not just a declarative state — that’s the big change for me.” As a result, Cloud Life made System Initiative the default — bundling it into AWS services, with six new projects last quarter spanning greenfield and migration work.

At the end of the day, end users don’t care about infrastructure maintenance. “Customers can’t give a shit less about Terraform,” says Ryke. “They care about the application and where it runs.” Without a steep Terraform hill to die on, Cloud Life now can hand off a visual model of infrastructure to customers to maintain.

Introducing a new way of working is no quick fix. “We’re fundamentally trying to transform some of the hardest problems,” says Jacob. “It’s not going to happen overnight.”

Because System Initiative is a fundamentally new model, migrations will be challenging for teams with large, prebuilt automations. As with any major technology shift, the transition will involve significant upfront work and gradual progress.

As such, Jacob recommends testing iteratively, observing workflow changes, and replacing parts over time. For now, lower-hanging fruit includes greenfield apps or large-scale deployments that never implemented IaC in the first place.

Preconceptions are another barrier. “A lot of hardcore people are very put off by it,” admits Ryke, comparing it to the original hesitancy about moving into the cloud. “It will upset the ecosystem.”

Jacob is sympathetic, acknowledging that “ClickOps” — i.e., provisioning infrastructure by clicking through GUIs — had its faults. Those paradigms failed because they sacrificed power and completeness for usability, he says. “But if you don’t sacrifice anything, they can accelerate you dramatically.”

For Cloud Life’s purposes, Ryke doesn’t see any sacrifices moving to the System Initiative model. That said, it might be overkill for more predictable, repeatable infrastructure. “When you do the exact same thing every day, the programmatic nature of IaC makes a lot of sense.”

To his point, some teams thrive with Terraform, especially those with stable infrastructure patterns. Meanwhile, other tools are also pushing to modernize IaC — like Crossplane, CDK for Terraform, and OpenTofu modules. Some platform engineering solutions are going further, abstracting infrastructure management altogether.

System Initiative still shows signs of a product in early growth, adds Ryke: some friction points here and there, but a team eager to respond to fixes. He’s hoping for better information retrieval capabilities and broader OS support over time. Jacob adds that cloud support beyond AWS (for Google Cloud Platform and Microsoft Azure) is still on the horizon.

Finally, costs and openness could be potential drawbacks. Although the code that powers System Initiative is completely open source, the product itself is priced. “There is no free distribution of System Initiative,” clarifies Jacob.

Software trends have shifted dramatically — languages have come and gone, release cycles have shrunk from months to hours, architectures have evolved, and AI has taken the industry by storm. Yet the code that automates software deployment and infrastructure has remained largely unchanged.

“The state of infrastructure automation right now is roughly equivalent to the way the world looked before the CRM was invented,” says Jacob.

A skeptic might ask, why not use generative AI to do IaC? Well, according to Jacob, the issue is data — or rather, the lack of it. “Most people think LLMs are magic. They’re not. It’s a technology like anything else.”

LLM-powered agents need structured, relationally rich data to act — something traditional infrastructure tools don’t typically expose. System Initiative provides the high-fidelity substrate those models need, says Jacob. Therefore, System Initiative and LLMs could be highly complementary, bringing more AI into devops over time. “If we want that magical future, this is a prerequisite.”

System Initiative proposes a major overhaul to infrastructure automation. By replacing difficult-to-maintain configuration code with a data-driven digital model, System Initiative promises to both streamline devops and eliminate IaC-related headaches. But it still has gaps, like minimal cloud support, and few proven case studies.

There’s also the risk of locking into a proprietary execution model that replaces traditional IaC, which will be a hard pill for many organizations to swallow.

Still, that might not matter. If System Initiative succeeds, the use cases grow, and the digital-twin approach delivers the results, a new day may well dawn for devops.
paserbyp: (Default)
paserbyp ([personal profile] paserbyp) wrote2025-07-14 11:30 am
Entry tags:
anais_pf: (Default)
anais_pf ([personal profile] anais_pf) wrote in [community profile] thefridayfive2025-07-11 12:59 am

The Friday Five for 11 July 2025

This week's questions were suggested by [livejournal.com profile] silent_r_infork

1. What was the most sick that you've ever been?

2. What disease are you afraid of getting?

3. Are you a big baby when it comes to taking medicine/shots for your illnesses?

4. Is going to the doctor really THAT bad?

5. Would you have the flu twice a month if you were paid $1,000 for having it?

Copy and paste to your own journal, then reply to this post with a link to your answers. If your journal is private or friends-only, you can post your full answers in the comments below.

If you'd like to suggest questions for a future Friday Five, then do so on DreamWidth or LiveJournal. Old sets that were used have been deleted, so we encourage you to suggest some more!