Skip to main content

Tesla Moves Towards Launching an Uber Competitor

2 months 1 week ago
"Tesla is taking steps to launch a ride-sharing service that could compete directly with Uber, Lyft and Waymo," reports Axios, noting that Tesla "has filed for a transportation charter-party carrier permit from the California Public Utilities Commission, Bloomberg reported Thursday." "That classification means Tesla would own and control the fleet of vehicles," Bloomberg reported... "In its communications with California officials, Tesla discussed driver's license information and drug-testing coordination, suggesting the company intends to use human drivers, at least initially," Bloomberg reported. The company is seeking the same type of permit that Waymo uses to run its robotaxi business.Uber is gearing up to begin offering autonomous vehicle services in partnership with Waymo in Austin and Atlanta later this year. The article also adds that Musk "told investors in January that 'I'm confident that we will release unsupervised FSD in California this year,' referring to the company's Full Self-Driving system." But "Tesla has yet to apply for a permit to operate driverless vehicles..." notes the EV blog Electrek, adding "This is just a step for Tesla to test ride-hailing services ahead of autonomy." Reuters also points out that "Earlier in October, Tesla revealed the Cybercab, a robotaxi concept that had no steering wheel or control pedals... He has said the Cybercab will go into production in 2026 and will also be available for customers to buy for less than $30,000."

Read more of this story at Slashdot.

EditorDavid

Clarifications and corrections

2 months 1 week ago
A front-page headline in The Mail on Sunday on Jan 5 said that a poll predicted that Keir Starmer would be ousted as Prime Minister within a year.

Google Calls for Measurable Memory-Safety Standards for Software

2 months 1 week ago
Memory safety bugs are "eroding trust in technology and costing billions," argues a new post on Google's security blog — adding that "traditional approaches, like code auditing, fuzzing, and exploit mitigations — while helpful — haven't been enough to stem the tide." So the blog post calls for a "common framework" for "defining specific, measurable criteria for achieving different levels of memory safety assurance." The hope is this gives policy makers "the technical foundation to craft effective policy initiatives and incentives promoting memory safety" leading to "a market in which vendors are incentivized to invest in memory safety." ("Customers will be empowered to recognize, demand, and reward safety.") In January the same Google security researchers helped co-write an article noting there are now strong memory-safety "research technologies" that are sufficiently mature: memory-safe languages (including "safer language subsets like Safe Buffers for C++"), mathematically rigorous formal verification, software compartmentalization, and hardware and software protections. (With hardware protections including things like ARM's Memory Tagging Extension and the (Capability Hardware Enhanced RISC Instructions, or "CHERI", architecture.) Google's security researchers are now calling for "a blueprint for a memory-safe future" — though Importantly, the idea is "defining the desired outcomes rather than locking ourselves into specific technologies." Their blog post this week again urges a practical/actionable framework that's commonly understood, but one that supports different approaches (and allowing tailoring to specific needs) while enabling objective assessment: At Google, we're not just advocating for standardization and a memory-safe future, we're actively working to build it. We are collaborating with industry and academic partners to develop potential standards, and our joint authorship of the recent CACM call-to-action marks an important first step in this process... This commitment is also reflected in our internal efforts. We are prioritizing memory-safe languages, and have already seen significant reductions in vulnerabilities by adopting languages like Rust in combination with existing, wide-spread usage of Java, Kotlin, and Go where performance constraints permit. We recognize that a complete transition to those languages will take time. That's why we're also investing in techniques to improve the safety of our existing C++ codebase by design, such as deploying hardened libc++. This effort isn't about picking winners or dictating solutions. It's about creating a level playing field, empowering informed decision-making, and driving a virtuous cycle of security improvement... The journey towards memory safety requires a collective commitment to standardization. We need to build a future where memory safety is not an afterthought but a foundational principle, a future where the next generation inherits a digital world that is secure by design. The security researchers' post calls for "a collective commitment" to eliminate memory-safety bugs, "anchored on secure-by-design practices..." One of the blog post's subheadings? "Let's build a memory-safe future together." And they're urging changes "not just for ourselves but for the generations that follow."

Read more of this story at Slashdot.

EditorDavid