Craig Mod: I love fast software. That is, software speedy both in function and interface. Software with minimal to no lag between wanting to activate or manipulate something and the thing happening. Lightness. Software that's speedy usually means it's focused. Like a good tool, it often means that it's simple, but that's not necessarily true. Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance. Fastness in software is like great margins in a book -- makes you smile without necessarily knowing why. [...]

Speed and reliability are often intuited hand-in-hand. Speed can be a good proxy for general engineering quality. If an application slows down on simple tasks, then it can mean the engineers aren't obsessive detail sticklers. Not always, but it can mean disastrous other issues lurk. I want all my craftspeople to stickle. I don't think Ulysses (a popular text editing application) is badly made, but I am less confident in it than if it handled input and interface speed with more grace. Speed would make me trust it more.

An anonymous reader shares a report: The impact of U.S. trade restrictions is trickling down to the developer community. GitHub, the world's largest host of source code, is preventing users in Iran, Syria, Crimea and potentially other sanctioned nations from accessing portions of the service, chief executive of the Microsoft-owned firm said. Over the weekend, GitHub CEO Nat Friedman wrote on Twitter that like any other "company that does business in the US," GitHub is required to comply with the U.S. export law. The confirmation comes months after work collaboration service Slack, too, enforced similar restrictions on its platform.,

An anonymous reader quotes The Verge's AI and Robotics reporter: By scanning huge datasets of text, machine learning software can produce convincing samples of everything from short stories to song lyrics. Now, those same techniques are being applied to the world of coding with a new program called Deep TabNine, a "coding autocompleter." Programmers can install it as an add-on in their editor of choice, and when they start writing, it'll suggest how to continue each line, offering small chunks at a time. Think of it as Gmail's Smart Compose feature but for code.

Jacob Jackson, the computer science undergrad at the University of Waterloo who created Deep TabNine, says this sort of software isn't new, but machine learning has hugely improved what it can offer... Earlier this month, he released an updated version that uses a deep learning text-generation algorithm called GPT-2, which was designed by the research lab OpenAI, to improve its abilities. The update has seriously impressed coders, who have called it "amazing," "insane," and "absolutely mind-blowing" on Twitter...

Deep TabNine is trained on 2 million files from coding repository GitHub. It finds patterns in this data and uses them to suggest what's likely to appear next in any given line of code, whether that's a variable name or a function... Most importantly, thanks to the analytical abilities of deep learning, the suggestions Deep TabNine makes are of a high overall quality. And because the software doesn't look at users' own code to make suggestions, it can start helping with projects right from the word go, rather than waiting to get some cues from the code the user writes.
It's not free software. Currently a personal license costs $49 (with a business-use license costing $99), the Verge reports -- but the tool supports the following 22 languages...

Python, JavaScript, Java, C++, C, PHP, Go, C#, Ruby, Objective-C, Rust, Swift, TypeScript, Haskell, OCaml, Scala, Kotlin, Perl, SQL, HTML, CSS, and Bash.

DevNull127 writes: Hiring is broken and yours is too," argues a New York-based software developer whose LinkedIn profile says he's worked at both Amazon and Google, as well as doing architecture verification work for both Oracle and Intel. Summarizing what he's read about hiring just this year in numerous online articles, he lists out the arguments against virtually every popular hiring metric, ultimately concluding that "Until and unless someone does a rigorous scientific study evaluating different interviewing techniques, preferably using a double-blind randomized trial, there's no point in beating this dead horse further. Everyone's hiring practices are broken, and yours aren't any better."

For example, as a Stanford graduate he nonetheless argues that "The skills required for getting into Stanford at 17 (extracurriculars, SAT prep etc) do not correlate to job success as a software developer. How good a student you were at 17, is not very relevant to who you are at 25." References are flawed because "People will only ever list references who will say good things about them," and they ultimately punish people who've had bad managers. But asking for source code from past sides projects penalizes people with other interests or family, while "most work product is confidential."

Brain teasers "rely on you being lucky enough to get a flash of inspiration, or you having heard it before," and are "not directly related to programming. Even Google says it is useless." And live-coding exercises are "artificial and contrived," and "not reflective of practical coding," while pair programming is unrealistic, with the difficulty of the tasks varying from day to day.

He ultimately criticizes the ongoing discussion for publicizing the problems but not the solutions. "How exactly should we weigh the various pros and cons against each other and actually pick a solution? Maybe we could maybe try something novel like data crunch the effectiveness of each technique, or do some randomized experiments to measure the efficacy of each approach? Lol, j/k. Ain't nobody got time for that!"

After a developer based in the Crimea region of Ukraine was blocked from GitHub this week, the Microsoft-owned software development platform said it has started restricting accounts in countries facing U.S. trade sanctions. GitHub lists Crimea, Cuba, Iran, North Korea, and Syris as countries facing U.S. sanctions. ZDNet reports: As the developer reports, his website https://tkashkin.tk, which is hosted on GitHub, now returns a 404 error. He also can't create new private GitHub repositories or access them. While his website could easily be moved to another hosting provider, the block does pose a challenge for his work on GameHub, which has an established audience on GitHub.

GitHub does offer developers an appeal form to dispute restrictions but [the developer] told ZDNet that, at this point, there's nothing to gain by appealing the restriction. "It is just pointless. My account is flagged as restricted and, in order to unflag it, I have to provide a proof that I don't live in Crimea. I am in fact a Russian citizen with Crimean registration, I am physically in Crimea, and I am living in Crimea my entire life," he said. "For individual users, who are not otherwise restricted by U.S. economic sanctions, GitHub currently offers limited restricted services to users in these countries and territories. This includes limited access to GitHub public repository services for personal communications only," it says.

GitHub notes on its page about U.S. trade controls that its paid-for on-premise software -- aimed to enterprise users -- may be an option for users in those circumstances. "Users are responsible for ensuring that the content they develop and share on GitHub.com complies with the U.S. export control laws, including the EAR (Export Administration Regulations) and the U.S. International Traffic in Arms Regulations (ITAR)," GitHub says. "The cloud-hosted service offering available at Github.com has not been designed to host data subject to the ITAR and does not currently offer the ability to restrict repository access by country. If you are looking to collaborate on ITAR- or other export-controlled data, we recommend you consider GitHub Enterprise Server, GitHub's on-premises offering."

New submitter Grindop53 shares a report: Widespread reports of a "critical security issue" that supposedly impacted users of VLC media player have been debunked as "completely bogus" by developers. Earlier this week, German computer emergency response team CERT-Bund -- part of the Federal Office for Information Security (BSI) -- pushed out an advisory warning network administrators and other users of a high-impact vulnerability in VLC. It seems that this advisory can be traced back to a ticket that was opened on VLC owner VideoLAN's public bug tracker more than four weeks ago. The alleged heap-based buffer overflow flaw was disclosed by a user named "topsec(zhangwy)," who stated that a malicious .mp4 file could be leveraged by an attacker to take control of VLC media player users' devices. The issue was flagged as high-risk on the CERT-Bund site, and the vulnerability was assigned a CVE entry (CVE-2019-13615).

However, according to VideoLAN president Jean-Baptiste Kempf, the exploit does not work on the latest VLC build. In fact, any potential issues relating to the vulnerability were patched more than a year ago. "There is no security issue in VLC," Kempf told The Daily Swig in a phone conversation this morning. "There is a security issue in a third-party library, and a fix was pushed [out] 18 months ago." When asked how or why this oversight generated so much attention, Kempf noted that the reporter of the supposed vulnerability did not approach VideoLAN through its security reporting email address. "The guy never contacted us," said Kempf, who remains a lead developer at the VLC project. "This is why you don't report security issues on a public bug tracker." Kempf and his team were unable to replicate the issue in the latest version of VLC, leading many to believe that the bug reporter was working on a computer running an outdated version of Ubuntu. "If you report a security issue, at least update your Linux distribution," Kempf said.

Apple's mobile apps routinely appear first in search results ahead of competitors in its App Store, a powerful advantage that skirts some of the company's rules on such rankings, according to a Wall Street Journal analysis. From the report: The company's apps ranked first in more than 60% of basic searches, such as for "maps," [Editor's note: the link may be paywalled; alternative source] the analysis showed. Apple apps that generate revenue through subscriptions or sales, like Music or Books, showed up first in 95% of searches related to those apps. This dominance gives the company an upper hand in a marketplace that generates $50 billion in annual spending. Services revenue linked to the performance of apps is at the center of Apple's strategy to diversify its profits as iPhone sales wane. While many of Apple's products are undoubtedly popular, they are held to a different standard by the App Store. Apple tells developers that downloads, user reviews and ratings are factors that influence search results. Yet more than two dozen of Apple's apps come pre-installed on iPhones and are shielded from reviews and ratings.

[...] Audiobooks.com, an RBmedia company, largely held the No. 1 ranking in "audiobooks" searches in the App Store for nearly two years. Then last September it was unseated by Apple Books. The Apple app had only recently begun marketing audiobooks directly for the first time. "It was literally overnight," said Ian Small, Audiobooks.com's general manager. He said the change triggered a 25% decline in Audiobooks.com's daily app downloads. [...] Apple's role as both the creator of the App Store's search engine and the beneficiary of its results has rankled developers. They contend Apple is essentially pinning its apps No. 1, compelling anyone seeking alternatives to consider Apple apps first. [...] Phillip Shoemaker, who led the App Store review process until 2016, said Apple executives were aware of Podcasts' poor ratings. Around 2015, his team proposed to senior executives that it purge all apps rated lower than two stars to ensure overall quality. "That would kill our Podcasts app," an Apple executive said, according to Mr. Shoemaker, who has advised some independent apps on the App Store review process since leaving Apple. The proposal was eventually rejected, Mr. Shoemaker said.

Senior full-stack engineer Ilya Suzdalnitski recently published a lively 6,000-word essay calling object-oriented programming "a trillion dollar disaster." Precious time and brainpower are being spent thinking about "abstractions" and "design patterns" instead of solving real-world problems... Object-Oriented Programming (OOP) has been created with one goal in mind -- to manage the complexity of procedural codebases. In other words, it was supposed to improve code organization. There's no objective and open evidence that OOP is better than plain procedural programming... Instead of reducing complexity, it encourages promiscuous sharing of mutable state and introduces additional complexity with its numerous design patterns. OOP makes common development practices, like refactoring and testing, needlessly hard...

Using OOP is seemingly innocent in the short-term, especially on greenfield projects. But what are the long-term consequences of using OOP? OOP is a time bomb, set to explode sometime in the future when the codebase gets big enough. Projects get delayed, deadlines get missed, developers get burned-out, adding in new features becomes next to impossible. The organization labels the codebase as the "legacy codebase", and the development team plans a rewrite.... OOP provides developers too many tools and choices, without imposing the right kinds of limitations. Even though OOP promises to address modularity and improve reusability, it fails to deliver on its promises...

I'm not criticizing Alan Kay's OOP -- he is a genius. I wish OOP was implemented the way he designed it. I'm criticizing the modern Java/C# approach to OOP... I think that it is plain wrong that OOP is considered the de-facto standard for code organization by many people, including those in very senior technical positions. It is also wrong that many mainstream languages don't offer any other alternatives to code organization other than OOP.
The essay ultimately blames Java for the popularity of OOP, citing Alan Kay's comment that Java "is the most distressing thing to happen to computing since MS-DOS." It also quotes Linus Torvalds's observation that "limiting your project to C means that people don't screw things up with any idiotic 'object model'."

And it ultimately suggests Functional Programming as a superior alternative, making the following assertions about OOP:

• "OOP code encourages the use of shared mutable state, which has been proven to be unsafe time and time again... [E]ncapsulation, in fact, is glorified global state."
• "OOP typically requires a lot of boilerplate code (low signal-to-noise ratio)."
• "Some might disagree, but OOP code is notoriously difficult to unit test... [R]efactoring OOP code is really hard without dedicated tools like Resharper."
• "It is impossible to write good and maintainable Object-Oriented code."

GitLab's CEO and co-founder says there was one big takeaway from their recent "2019 Global Developer Report: DevSecOps": that early adopters of a strong Devops model experience greater security. "Security teams in a longstanding DevOps environment reported they are three times more likely to discover bugs before code is merged," according to the GitLab blog, "and 90% more likely to test between 91% and 100% of code than teams who encounter early-stage DevOps."

But after polling over 4,000 software professionals, the survey also found positive results from another workplace arrangement, which they report under the headline "Remote work works." According to our survey respondents, working remotely leads to greater collaboration, better documentation, and transparency.

In fact, developers in a mostly remote environment are 23% more likely to have good insight into what colleagues are working on and rate the maturity of their organization's security practices 29% higher than those who work in a traditional office environment.

Google's Go programming language will not add a try() function in its next major version, "despite this being a major part of what was proposed," reports the Register: Error handling in Go is currently based on using if statements to compare a returned error value to nil. If it is nil, no error occurred. This requires developers to write a lot of if statements. "In general Go programs have too much code-checking errors and not enough code handling them," wrote Google principal engineer Russ Cox in an overview of the error-handling problem in Go.

There was therefore a proposal to add a built-in try function which lets you eliminate many of the if statements and triggers a return from a function if an error is detected. The proposal was not for full exception handling, which is already present in Go via the panic and recover functions. That proposal has now been abandoned. Robert Griesemer, one of the original designers of Go, announced the decision in a post Tuesday...

"Based on the overwhelming community response and extensive discussion here, we are marking this proposal declined ahead of schedule. As far as technical feedback, this discussion has helpfully identified some important considerations we missed, most notably the implications for adding debugging prints and analyzing code coverage.

"More importantly, we have heard clearly the many people who argued that this proposal was not targeting a worthwhile problem. We still believe that error handling in Go is not perfect and can be meaningfully improved, but it is clear that we as a community need to talk more about what specific aspects of error handling are problems that we should address."

"Everyone knows security needs to be baked into the development lifecycle, but that doesn't mean it is," writes ZDNet, reporting on a new survey they say showed that "long-standing friction between security and development teams remain."

The results came from GitLab's "2019 Global Developer Report: DevSecOps" survey of over 4,000 software professionals. Nearly half of security pros surveyed, 49%, said they struggle to get developers to make remediation of vulnerabilities a priority. Worse still, 68% of security professionals feel fewer than half of developers can spot security vulnerabilities later in the life cycle. Roughly half of security professionals said they most often found bugs after code is merged in a test environment.

At the same time, nearly 70% of developers said that while they are expected to write secure code, they get little guidance or help. One disgruntled programmer said, "It's a mess, no standardization, most of my work has never had a security scan." Another problem is it seems many companies don't take security seriously enough. Nearly 44% of those surveyed reported that they're not judged on their security vulnerabilities.
ZDNet also cites Linus Torvalds' remarks on the Linux kernel mailing list in 2017, complaining about how security people celebrate when code is hardened against an invalid access. "[F]rom a developer standpoint, things really are not done. Not even close. From a developer standpoint, the bad access was just a symptom, and it needs to be reported, and debugged, and fixed, so that the bug actually gets corrected. So from a developer standpoint, the end point of hardening is just the starting point, and when you think you're done, we're really only getting started."

Torvalds then pointed out that the user community also has a third set of entirely different expectations, adding that "the number one rule of kernel development is that 'we don't break users'. Because without users, your program is pointless, and all the development work you've done over decades is pointless... and security is pointless too, in the end." Juggling the interest of users and developers, Torvalds suggests security people should adopt "do no harm" as their mantra, and "when adding hardening features, the first step should *ALWAYS* be 'just report it'. Not killing things, not even stopping the access. Report it. Nothing else."

An anonymous reader quotes the Atlantic: Suze Orman wants young people to stop "peeing" away millions of dollars on coffee. Last month, the personal-finance celebrity ignited a controversy on social media when a video she starred in for CNBC targeted a familiar villain: kids these days and their silly $5 lattes. Because brewing coffee at home is less expensive, Orman argued, purchasing it elsewhere is tantamount to flushing money away, which makes it a worthy symbol of Millennials' squandered resources...

In the face of coffee shaming, young people usually point to things like student loans and housing prices as the true source of the generation's instability, not their $100-a-month cold-brew habits... Orman and her compatriots now receive widespread pushback when denigrating coffee aficionados, a change that reflects the shifting intergenerational tensions that are frequently a feature of the post-Great Recession personal-finance genre. The industry posits that many of the sweeping generational trends affecting Americans' personal stability -- student-loan debt, housing insecurity, the precarity of the gig economy -- are actually the fault of modernity's encouragement of undisciplined individual largesse. In reality, those phenomena are largely the province of Baby Boomers, whose policies set future generations on a much tougher road than their own. With every passing year, it becomes harder to sell the idea that the problems are simply with each American as a person, instead of with the system they live in. "There's a reason for this blame-the-victim talk" in personal-finance advice, the journalist Helaine Olen wrote recently. "It lets society off the hook. Instead of getting angry at the economics of our second gilded age, many end up furious with themselves."

That misdirection is useful for people in power, including self-help gurus who want to sell books... [W]hen it comes to money, says Laura Vanderkam, the author of All the Money in the World: What the Happiest People Know About Getting and Spending, there are usually only a couple of things that actually make a difference in how stable people are. It's the big stuff: how much you make, how much you pay for housing, whether or not you pay for a car.

An anonymous reader quotes LWN: Python 3.8 is feature complete at this point, which makes it a good time to see what will be part of it when the final release is made. That is currently scheduled for October, so users don't have that long to wait to start using those new features.

The headline feature for Python 3.8 is also its most contentious. The process for deciding on Python Enhancement Proposal (PEP) 572 ("Assignment Expressions") was a rather bumpy ride that eventually resulted in a new governance model for the language. That model meant that a new steering council would replace longtime benevolent dictator for life (BDFL) Guido van Rossum for decision-making, after Van Rossum stepped down in part due to the "PEP 572 mess".

Out of that came a new operator, however, that is often called the "walrus operator" due to its visual appearance. Using ":=" in an if or while statement allows assigning a value to a variable while testing it... It is a feature that many other languages have, but Python has, of course, gone without it for nearly 30 years at this point. In the end, it is actually a fairly small change for all of the uproar it caused.

Todd Austin, a professor at the University of Michigan, is working on an approach known as Morpheus that aims to frustrate hackers trying to gain control of microchips by presenting them with a rapidly changing target. At a conference in Detroit this week organized by the U.S. Defense Department's Defense Advanced Research Projects Agency (DARPA), Austin described how the prototype Morpheus chip works. MIT Technology Review reports: The aim is to make it incredibly difficult for hackers to exploit key software that helps govern the chip's operation. Morpheus does this by repeatedly randomizing elements of the code that attackers need access to in order to compromise the hardware. This can be achieved without disrupting the software applications that are powered by the processor. Austin has been able to get the chip's code "churning" to happen once every 50 milliseconds -- way faster than needed to frustrate the most powerful automated hacking tools. So even if hackers find a vulnerability, the information needed to exploit it disappears in the blink of an eye.

There's a cost to all this: the technology causes a slight drop in performance and requires somewhat bigger chips. The military may accept this trade-off in return for greater security on the battlefield, but it could limit Morpheus's appeal to businesses and consumers. Austin said a prototype has already resisted every known variant of a widely-used hacking technique known as a control-flow attack, which does things like tampering with the way a processor handles memory in order to allow hackers to sneak in malware. More tests lie ahead. A team of U.S. national security experts will soon begin probing the prototype chip to see if they can compromise its defenses, and Austin also plans to post some of Morpheus's code online so that other researchers can try to find flaws in it, too.

Microsoft plans to explore using the Rust programming language as an alternative to C, C++, and others, as a way to improve the security posture of its and everyone else's apps. From a report: The announcement was made yesterday by Gavin Thomas, Principal Security Engineering Manager for the Microsoft Security Response Center (MSRC). "You're probably used to thinking about the Microsoft Security Response Center as a group that responds to incidents and vulnerabilities," Thomas said. "We are a response organization, but we also have a proactive role, and in a new blog series we will highlight Microsoft's exploration of safer system programming languages, starting with Rust." The end game is to find a way to move developers from the aging C and C++ programming language to so-called "memory-safe languages." Memory-safe languages, such as Rust, are designed from the ground up with protections against memory corruption vulnerabilities, such as buffer overflows, race conditions, memory leaks, use-after free and memory pointer-related bugs.

Former Supreme Court Justice John Paul Stevens passed away Tuesday evening of complications following a stroke he suffered on July 15. He was 99 years old. An anonymous Slashdot reader shares a lightly edited version of Ars Technica's 2010 story that originally marked his retirement from the Supreme Court: In April 2010, the Supreme Court's most senior justice, John Paul Stevens, announced his retirement. In the weeks that followed, hundreds of articles were written about his career and his legacy. While most articles focus on 'hot button' issues such as flag burning, terrorism, and affirmative action, Stevens' tech policy record has largely been ignored. When Justice Stevens joined the court, many of the technologies we now take for granted -- the PC, packet-switched networks, home video recording -- were in their infancy. During his 35-year tenure on the bench, Stevens penned decisions that laid the foundation for the tremendous innovations that followed in each of these areas.

For example, Stevens penned the 1978 decision that shielded the software industry from the patent system in its formative years. In 1984, Hollywood's effort to ban the VCR failed by just one Supreme Court vote; Stevens wrote the majority opinion. And in 1997, he wrote the majority opinion striking down the worst provisions of the Communications Decency Act and ensuring that the Internet would have robust First Amendment protections. Indeed, Justice Stevens probably deserves more credit than any other justice for the innovations that occurred under his watch. And given how central those technologies have become to the American economy, Stevens' tech policy work may prove one of his most enduring legacies. In this feature, we review Justice Stevens' tech policy decisions and salute the justice who helped make possible DRM-free media devices, uncensored Internet connections, free software, and much more. As the report mentions, Stevens was the Supreme Court's cryptographer. "Stevens attended the University of Chicago, graduating in 1941. On December 6 -- the day before the Japanese attacked Pearl Harbor -- Stevens enrolled in the Navy's correspondence course on cryptography."

"Stevens spent the war in a Navy bunker in Hawaii, doing traffic analysis in an effort to determine the location of Japanese ships," the report adds. "He was an English major, not a mathematician, but he proved to have a knack for cryptographic work."

Slashdot reader DevNull127 writes: Another very minor kerfuffle has broken out in the community for the Go programming language. When its official Twitter account asked for feedback on the new look of its web site, one developer suggested that it had been a mistake to add the Google logo to the lower-right of the home page. "A lot of people associate it with a commercial Google product."

Following the suggested procedure, he then created an issue on GitHub. ("Go is perceived by some as a pure Google project without community involvement. Adding a Google logo does not help in this discussion.") The issue received 61 upvotes (and 30 downvotes), eventually receiving a response from Google software engineer Andrew Bonventre, the engineering lead on the Go Team.

"Thanks for the issue. We spent a long time talking about it and are sensitive to this concern. It's equally important to make it clear that Google supports Go, which was missing before (Much like typescriptlang.org). Google pays for and hosts the infrastructure that golang.org runs on and we hope the current very small logo is a decent compromise." He then closed the issue.

The developer who created the issue then responded, "I get that you've discussed this internally. This is a great opportunity to discuss it with the community. I'm thankful to Google for financing the initial and ongoing development of Go but Google is not the only company investing [in] Go. I would like to move the Google logo into an separate section, together will the major stakeholders of the project."

In a later comment he added "I value Google's participation in Go and I'm not arguing to change that. Having the Google logo in the corner of each golang.org page suggests that this is a pure Google project when it is not..."

For some perspective, another Go developer had also suggested "animate the gopher's eyes on the website."

"Thanks, but we're not going to do this," responded the engineering lead on the Go Team. "We've discussed it before and it would be way too distracting."

Cloudflare has published a detailed and refreshingly honest report into precisely what went wrong earlier this month when its systems fell over and took a big chunk of the internet with it. The Register reports: We already knew from a quick summary published the next day, and our interview with its CTO John Graham-Cumming, that the 30-minute global outage had been caused by an error in a single line of code in a system the company uses to push rapid software changes. [...] First up the error itself -- it was in this bit of code: .*(?:.*=.*). We won't go into the full workings as to why because the post does so extensively (a Friday treat for coding nerds) but very broadly the code caused a lot of what's called "backtracking," basically repetitive looping. This backtracking got worse -- exponentially worse -- the more complex the request and very, very quickly maxed out the company's CPUs.

The impact wasn't noticed for the simple reason that the test suite didn't measure CPU usage. It soon will -- Cloudflare has an internal deadline of a week from now. The second problem was that a software protection system that would have prevented excessive CPU consumption had been removed "by mistake" just a weeks earlier. That protection is now back in although it clearly needs to be locked down. The software used to run the code -- the expression engine -- also doesn't have the ability to check for the sort of backtracking that occurred. Cloudflare says it will shift to one that does. The post goes on to talk about the speed with which it impacted everyone, why it took them so long to fix it, and why it didn't just do a rollback within minutes and solve the issue while it figured out what was going on.

You can read the full postmortem here.

Last year, Oracle filed a lawsuit against the U.S. government complaining about the procurement process around the Pentagon's $10 billion, decade-long JEDI cloud contract. "They claimed a potential conflict of interest on the part of a procurement team member (who was a former AWS employee)," reports TechCrunch. "Today, that case was dismissed in federal court." From the report: In dismissing the case, Federal Claims Court Senior Judge Eric Bruggink ruled that the company had failed to prove a conflict in the procurement process, something the DOD's own internal audits found in two separate investigations. Judge Bruggink ultimately agreed with the DoD's findings: "We conclude as well that the contracting officer's findings that an organizational conflict of interest does not exist and that individual conflicts of interest did not impact the procurement, were not arbitrary, capricious, an abuse of discretion, or otherwise not in accordance with law. Plaintiff's motion for judgment on the administrative record is therefore denied."

Today's ruling opens the door for the announcement of a winner of the $10 billion contract, as early as next month. The DoD previously announced that it had chosen Microsoft and Amazon as the two finalists for the winner-take-all bid.

Security engineer Ivan writes: For some reason Apple allows "subscription scam" apps on the App Store. These are apps that are free to download and then ask you to subscribe right on launch. It's called the freemium business model, except these apps ask you to subscribe for "X" feature(s) immediately when you launch them, and keep doing so, annoyingly, over and over until you finally subscribe. By subscribing you get a number of "free days" (trial) and then they charge you weekly/monthly/yearly for very basic features like scanning QR Codes.

I've been trying to monitor apps that have these characteristics: 1. They have In-App purchases for their subscriptions. 2. They have bad reviews, specially with words like "scam" or "fraud". 3. Their "good" reviews are generic, potentially bot-generated. This weekend I focused on 5 apps from 2 different developers and to my surprise they are very similar, not only their UI/UX but also their code is shared and their patterns are absolutely the same. A side from being classic subscription scam apps, I wanted to examine how they work internally and how they communicate with their servers and what type of information are they sending.