Barnet Rockingham

Reach, the owner of the UK's Daily Mirror and Daily Express tabloids among other newspapers, has started publishing articles with the help of AI software on one of its regional websites as it scrambles to cut costs amid slipping advertising revenues. The Register reports: Three stories written with the help of machine-learning tools were published on InYourArea.co.uk, which produces feeds of nearby goings-on in Blighty. One piece, titled Seven Things to do in Newport, is a listicle pulling together information on places and activities available in the eponymous sunny Welsh resort city. Reach CEO Jim Mullen said the machine-written articles are checked and approved by human editors before they're published online. "We produced our first AI content in the last ten days, but this is led by editorial," he said, according to The Guardian. "It was all AI-produced, but the data was obviously put together by a journalist, and whether it was good enough to publish was decided by an editor." "There are loads of ethics [issues] around AI and journalistic content," Mullen admitted. "The way I look at it, we produce lots of content based on actual data. It can be put together in a well-read [piece] that I think AI can do. We are trying to apply it to areas we already get traffic to allow journalists to focus on content that editors want written." Mullen's comments have been questioned by journalists, however, given that Reach announced plans to slash hundreds of jobs in January. The National Union of Journalists said 102 editorial positions would be cut, putting 253 journalists at risk, whilst 180 vacancies would be withdrawn.

Read more of this story at Slashdot.

With 'three funny titans of Saturday evening TV'

Comments

Facebook parent company Meta Platforms has stopped development of a new software operating system to power its virtual reality devices and upcoming augmented reality glasses, The Information reported Wednesday, citing people familiar with the decision. From a report: Shelving the project, which had been underway for several years and involved hundreds of employees, marked a setback for the company's attempt to own the underlying software behind its Oculus VR headset and future augmented or mixed reality devices. The screens of its planned devices aim to overlay digital images on the real world or weave real-world objects into VR apps. Meta uses an open-source version of Google's Android operating system to power Meta's existing Oculus Quest VR devices. But Meta wanted to create an OS from scratch to power them and future devices, a project that became known internally as XROS. XR is a catch-all term for VR, AR, and mixed reality. In MR, the wearer of a headset could view and use real-world objects, such as a keyboard, to do work or play games in a VR-like app. Instead, the company has told some staff it would continue to modify an open-source version of Android, which Google developed for smartphones but which other companies have used to power various devices, the people familiar with the matter said. Meta's modified version of Android, known internally as VROS, powers existing Oculus VR headsets.

Read more of this story at Slashdot.

Mark Gurman, reporting on Friday's ruling in Apple and Epic lawsuit: So how much does Apple stand to lose? That all comes down to how many developers try to bypass its payment system. Loup Venture's Gene Munster, a longtime Apple watcher, put the range at $1 billion to $4 billion, depending on how many developers take advantage of the new policy. Apple depicted the ruling as a victory, signaling that it's not too worried about the financial impact. "The court has affirmed what we've known all along: The App Store is not in violation of antitrust law" and "success is not illegal," Apple said in a statement. Kate Adams, the iPhone maker's general counsel, called the ruling a "resounding victory" that "underscores the merit" of its business. Apple's adversary in the trial -- Epic Games, the maker of Fortnite -- also contended that the judge sided with Apple. This "isn't a win for developers or for consumers," Epic Chief Executive Officer Tim Sweeney said on Twitter. [...] Apple made about $3.8 billion in U.S. revenue from games in 2020, most of which came from in-app purchases, according to estimates from Sensor Tower. But even if the ruling ends up costing Apple a few billion dollars a year, that's still a small fraction of its total revenue. In fiscal 2021 alone, the company is estimated to bring in more than $360 billion, meaning the change won't make or break its overall financial performance. And many developers may choose to stick to Apple's payment system so they don't have to build their own web payment platform. More concerns were shared by the EFF in a thread on Twitter. "Disappointingly, a court found that Apple is not a monopolist in mobile gaming or in-app transactions, so its App Store commissions don't violate antitrust law. One bright spot: the court found Apple's gag rules on app developers violate California law... "The court's opinion spells out many serious problems with today's mobile app ecosystem, such as false tensions between user choice and user privacy. Congress can help with real antitrust reform and new legal tools, and shouldn't let Apple's privacywashing derail that work."

Read more of this story at Slashdot.

Comments

Comments

Comments

Comments

Comments

Earlier this week, Nestle said it was jumping on the blockchain bandwagon, today, Starbucks said it is ready to top that. From a report: The Seattle-based coffee giant is working with Microsoft and a leading global exchange on a new digital platform that will allow consumers to use bitcoin and other cryptocurrencies at Starbucks. Starbucks along with Intercontinental Exchange, Microsoft and BCG, among others, is working to launch a new company called Bakkt that will enable consumers and institutions to buy, sell, store and spend cryptocurrencies on the global network by November. The platform with convert bitcoin and other cryptocoins into U.S. dollars that can be used to buy a Cold Foam Cascara Cold Brew, Matcha Lemonade or anything else at Starbucks. Starbucks has consistently been at the forefront of embracing new technologies. For instance, it added support for mobile payments in 2011. In May, it was estimated that Starbucks' mobile payment solution is more popular than those of Apple and Google. In a statement, Maria Smith, vice president of partnerships and payments for Starbucks, "As the flagship retailer, Starbucks will play a pivotal role in developing practical, trusted and regulated applications for consumers to convert their digital assets into US dollars for use at Starbucks. As a leader in Mobile Pay to our more than 15 million Starbucks Rewards members, Starbucks is committed to innovation for expanding payment options for our customers." According to Starbucks spokespeople, Motherboard reports, Starbucks doesn't want bitcoins, but it's willing to help people spend them -- the venture is an exchange that will allow people to convert their cryptocurrency into US dollars, which they can then spend at Starbucks locations.

Read more of this story at Slashdot.

An anonymous reader shares a report: Of the 100 images submitted to the 2018 Robotart competition, an automaton called CloudPainter rose to the top, with evocative portraits featuring varying degrees of abstraction. One of its winning images was created by a team of neural networks, AI algorithms, and robots. Robotart's founder, Andrew Conru, told MIT Technology Review that this year's entries have shown refined brushstrokes and composition. "CloudPainter, the winner this year, has been involved all three years and has made the most improvement in his system," he says. "The resulting work, while it still uses an inputted photo as reference, can execute paintings using different painting styles."

Read more of this story at Slashdot.

“Oh actually, I want a bright orange background. But that’s easy, right? Just one click in Photoshop?”

- My client, after I took 500+ photos with a white background, as requested. 

Earlier this year, Jimmy Wales, the founder of Wikipedia, said he would be launching a neutral news service with "no other agenda than this: the ultimate arbiter of the truth is the facts of reality." On Monday, a pilot version of WikiTribune went live. Adrianne Jeffries of The Outline argues that WikiTribune is already doing things that it said it wouldn't: As of this writing, WikiTribune's homepage featured a hodgepodge of news aggregation. The "editor's choice" module points to a news roundup that includes Paul Manafort's indictment, the Catalonian independence movement. [...] These stories are all sourced to fairly mainstream news outlets, including some that are on Wikipedia's preferred sources list such as CNN and Reuters, and some that are not, such as Politifact and "Spanish media." I admire what Wales is trying to do here. [...] But WikiTribune is bullshit. It's not new -- it is the same kind of news aggregation that exists all over the web. It is not better -- comparable summarizing and linking can be found on many websites, while original reporting of those same stories, often supplemented by linking to other reporting, can be found at CNN, Reuters, The New York Times, and the BBC, which WikiTribune uses as its primary sources. And finally, and most importantly, it is not neutral. The existence of the "Editor's choice" module, which highlights some stories over others, is not neutral; neither is the "Good reads" section, which does the same thing. The Manafort story includes a section, "Highlights from the indictment," which is not neutral -- someone had to decide which parts of the indictment were more significant than others. There is no such thing as an objective highlight. It is true that the wording of the story does not include adjectives, except when it quotes from the indictment ("lavish lifestyle," "false and misleading statements"), but this is standard newswriting, as one would get from the AP or the New York Times.

Read more of this story at Slashdot.

Comments

It's the 4th of July, which is the day the US attempts to forget they ever pretended to like soccer through wild displays of patriotism and fireworks. It's also a holiday, so enjoy this WTF from the archives, The Program Generator Program from 2012.

When you've been in IT for as long as Pat McGee, you're bound to have survived at least one or two COBOL horror stories. While COBOL is certainly not the worst platform to develop software on (MUMPS will most certainly hold that title through at least our grandchildren’s lifetimes), its extreme verbosity and unique idiosyncrasies make it a challenge for organizations to develop clean, maintainable code.

To COBOL's credit, it was one of the first attempts – actually, it was probably the first attempt – at self-obsolescence. Like today, the programmers of old were far too talented to meddle in trite matters like "business rules." After all, if the managers and analysts could conjure up these business rules, they could certainly write them up in a business-oriented language.  A COmmon Business-Oriented Language, if you will. Of course, we all know how that story ends, and five decades later, COBOL programmers are still paying for that arrogance today.

Back in the late '90s, Pat found himself doing exactly that. Unlike many of his colleagues, he wasn't working on any exciting Y2K bugs, but instead was tasked with something much more mundane: write a program to import several million records of COBOL-format, tape-based files into Oracle. While the hardware had long since had been upgraded to use "virtual tapes", they had not aged well.

At the heart of the system was a 10,000 line COBOL record descriptor from a design that started back in the 1960s – long before anyone had heard of 3rd Normal Form back then, much less believed it would be a good thing. Record descriptors aren't terribly difficult to follow; they mostly just map field names and data types to positions in a record.   For example, a simple descriptor would look like this:

   01 Employee-Rec.
       02 Employee-ID        PIC X(10).
       02 Employee-Name.
          03 Last-Name       PIC X(20).
          03 First-Name      PIC X(12).
          03 Middle-Init     PIC X.
       02 Position.
          03 Job-Code        PIC X(4).
          03 Department      PIC X(3).
          03 Manager-ID      PIC X(10).
       02 Hourly-Pay         PIC 9(3)V99.
       02 Past-Job-Codes.
          03 Past-Job-Code1  PIC X(4).
          03 Change-Date1.
             04 Change-Month1 PIC 99.
             04 Change-Day1   PIC 99.
             04 Change-Year1  PIC 99.
          03 Past-Job-Code2  PIC X(4).
          03 Change-Date2.
             04 Change-Month2 PIC 99.
             04 Change-Day2   PIC 99.
             04 Change-Year2  PIC 99.
          03 Past-Job-Code3  PIC X(4).
          03 Change-Date3.
             04 Change-Month3 PIC 99.
             04 Change-Day3   PIC 99.
             04 Change-Year3  PIC 99.

While a corresponding record would look like this:

ABCD123456MCGEE               JAMES       PACCTAR ABCD65432104250CLRK010195INTN010397

COBOL-format record and record descriptors don't respond to change very well, and like any piece of business software,  they are changed very often.  On the system Pat was working on, they changed very, very often. And this meant that any program that had to deal with the COBOL program's data (such as the Oracle record importer that Pat maintained), had to change just as often.

To make matters worse, Pat had absolutely no influence or visibility into the update process; he simply had to take the COBOL output and make it work. It was boring, tedious work, and Pat had all sorts of ideas on how to improve the process. Of course, it would have taken an Act of God for the customer to be willing to make any changes, and He definitely wasn't on Pat's team. What this meant was that Pat had to update the Oracle importer tool every week or so, whenever the customer made tweaks to the descriptor and corresponding files.

After the third or so week, Pat found that this simple tweak represented a whole lot hassle. The code changes were relatively easy, but they just kept coming and coming and coming. He thought about it for a bit, and figured that he could probably write something that would do exactly what he did: read the COBOL record descriptor and generate a new transfer mapping each time the format changed.

What he ended up with was a LEX/YACC grammar that described the COBOL record format, and some C sections for each parsed item. Those C sections generated a C++ program that implemented the translation. A quick compile of the C++ program and the translator program could chug along, happily reading the virtual tapes and writing text files that we could import into Oracle with the standard tools.

At least, that was the theory. As soon as he passed in the actual COBOL record descriptor, he learned that his LEX/YACC/C/C++ program couldn't quite handle all the oddities that the customer managed to include in the COBOL record descriptor. So he wrote some SED scripts to rewrite sections of the COBOL stuff before feeding it into the program. The SED script worked like a charm, and the program generator program spit out a perfect field translation map.

Then the customer requested another change. And then another. And then another. As it turned out, Pat hadn't quite managed to capture rules for all the really weird changes they could make in the COBOL record format. This meant that, almost every time the customer requested a change, Pat would then have to change the SED/LEX/YACC/C/C++ code, and then re-run it to regenerate the translator.

After a few months, Pat had re-written the SED/LEX/YACC/C/C++ code several times over, each time adding more and more validation capabilities. Despite all this, a change to his program-generator was required at least 50% of the time. And since no one else on his team was willing to learn anything about LEX and YACC, much less SED, the maintaining and executing the program generator became his primary responsibility.

The end came much sooner than Pat had expected. Not to the COBOL program or the project as a whole – just his particular assignment. He maintained ties with the folks in his group and learned that, the very next week after his last, the SED/LEX/YACC/C/C++ program stopped working. In response, the whole project was shut down for a month while someone wrote another C++ program, by hand, to do the translation. Of course, that person got stuck spending a couple of days each week updating the program.

But at least he had job security.

In the late 90s, Jeremy fought a battle against a menace more terrifying than the dreaded Y2K bug. He maintained a network management application running on Solaris which managed TDM and ATM switches, called PortLog. This prototype CMDB maintained a database of all of the equipment in the network. It created a unique identifier encoded each device’s shelf, slot and port number according to a “magic” formula. That formula needed to change in the next release, thus forcing the unique ID of each device to change as well, in every deployed instance of their database.

Ross, Jeremy’s boss and PortLog guru, provided Jeremy an update script to guide this conversion. One client volunteered to be a -guinea pig- pilot site. With appropriate permission in writing, Jeremy kicked the script off, expecting it to take 20 minutes tops. Surely just converting a bunch of numbers couldn’t take much longer than that, right? But Ross’ script kept running. And running. And…

…

…

…

running.

12 whole hours and a few cans of energy drink later, the script finally reported a successful completion. The pilot site was small, and took 12 hours to convert. How long would their much larger clients take? 12 hours of downtime wasn’t acceptable, and it was only going to get worse.

Jeremy poked through the database and found all the ID’s had been updated, but several of them had the same number, thus defeating the purpose of an ID field in the first place. Out of morbid curiosity, he cracked open Ross’ script to see what the hell it was doing. A MASSIVE stored procedure stared back at him like Godzilla peering through the window of a high-rise. Inside the procedure, there were foreach loops - one per table, once per piece of equipment. Inside all foreach loops, the key step looked like:

ON EXCEPTION 
  UPDATE <table> SET adp_no=<new value> WHERE …; --this fixes the duplicate key exception. Runs much faster now! - Ross
END EXCEPTION WITH RESUME;

It did indeed “fix” the duplicate key exception, by forcing the value to be set whenever any exception was thrown, including a duplicate key violation. Ross didn’t care that the equipment IDs ceased to be unique. And this made it “much faster”?

Jeremy paid Ross a visit. As diplomatically as possible, Jeremy explained to him everything that was wrong with the script, and how a much more reliable, efficient one could be created before their go-live date. The new script would be much shorter, easier to support, run in minutes, and most important: actually work. Ross, of course, wasn’t having any of it.

“No way, Jeremy!” Ross bellowed back at him. “It’s too late in the game to be throwing unknown stuff at this. My script has been tested and proven to work. You said yourself that it said ‘successful’ after it was done running. That means it works!”

“Ross, this thing took 12 whole hours to run for a medium-sized client, and the data wasn’t even right…” Jeremy pleaded. “If you’d just let me…”

“It printed ‘successful’! It wouldn’t have done that if it didn’t work!” Ross interrupted. He took a few moments to catch his breath, and then found the diplomatic solution: "I’m not perfect, but since you are, you can take my existing, TESTED script and modify it. Making something from scratch is out of the question in this time-frame so get started!

Jeremy slinked back to his desk and pondered his existence. Then a light bulb burst to life over his head. He could still make the quick, simple efficient script he wanted to and just Modify Ross’ script to call it and exit immediately. All of Ross’s code would still be there, so if Ross did a cursory examination of the script, nothing would look wrong. Since Ross rarely actually did the production releases, he’d never catch on.

The next weekend, Jeremy and his fellow engineers were prepared to assault their largest client’s data with the mean script he came up with. “Are we going to be here all weekend? I heard Ross’ conversion script took 12 hours for the pilot site.” a colleague asked.

“Don’t worry, I got this!” Jeremy said confidently. “I… um… tuned Ross’s script. But, ah… let’s keep this our little secret though because if Ross finds out how lean this monster can really be, his insecurity will boil over into rage.”

They were done with their work and out at the pub before sundown. Jeremy left an email for Ross to find Monday telling him how the minor tweaks he made to the script paid off, but of course Ross deserved most of the credit. Scriptzilla had been tamed, but the code remained in the script, like Godzilla lurking beneath the sea. Jeremy feared that it would one day rise again…