Like a normal featureless cube, but sings comical songs.
271 stories
·
8 followers

2001: A Space Odyssey Art Exhibit

2 Comments
Step inside one of cinema's most enduring masterpieces with a visit to the 2001: A Space Odyssey Immersive Art Exhibit. Also known as "The Barmecide Feast," this installation from artist...

Visit Uncrate for the full post.
Read the whole story
emdeesee
22 hours ago
reply
It may be time to make a pilgrimage to the National Air and Space Museum.
Lincoln, NE
MotherHydra
7 days ago
reply
I wish I could see this!
Space City, USA
Share this story
Delete

Google gives up on Google Allo, hopes carriers will sort out RCS messaging

1 Comment

It's time for another chapter in the saga of Google's messaging mess. This latest news comes from The Verge, which reports that Google will be abandoning its most recent messaging app failure, Google Allo, in favor of a renewed push for the carrier-controlled RCS (Rich Communication Services) protocol.

Google Allo was Google's attempt at a WhatsApp clone, and it launched just a year-and-a-half ago with a laundry list of deficiencies. It used a phone-centric login system and didn't support using a Google account. It only worked on one device at a time and didn't have an interface for desktop or laptop computers. Distribution wasn't great either, as Allo wasn't one of the mandatory Google apps included in every Android phone. None of this really mattered since Allo didn't support sending SMS messages, so there was no one to talk to anyway. Google's other chat service, Google Hangouts, was better in nearly every way.

With such a half-baked launch, the real unknown for Google Allo was what kind of resources Google would throw at it. Like Android, which also entered a market late in the game, Allo needed a massive amount of resources to catch up to the competition. Instead, we were treated to an absolutely glacial development pace that mostly focused on new sticker packs. It took

a full year

before Allo addressed one of its biggest flaws—not working on a desktop—and even then, login was handled by a janky QR code pairing system that only worked on one extra device at a time. Google users expect a Google account-based login that works on all devices all the time, just like Hangouts.

At least we won't have to worry about Allo anymore. The Verge report says Google is "pausing" Allo development and "transferring almost the entire team off the project and putting all its resources into another app." Allo will continue to work for the foreseeable future, but new features won't be arriving any time soon.

Rich (and fragmented) Communication Services

What everyone wants from Google is an iMessage clone: an over-the-top messaging service that would run on all devices and platforms, with login handed by a Google account. Essentially, people want an updated version of Google Hangouts, a piece of software Google abandoned and removed features from in order to promote Google Allo. The Verge report says that Google "won’t build the iMessage clone that Android fans have clamored for" and will instead try to get the carriers to cooperate on RCS.

RCS, or Rich Communication Services, has been around as a GSMA (the worldwide mobile network trade body) project for about ten years now. RCS replaces SMS and MMS with a service that works more like an instant messaging app. RCS adds IM features to carrier messaging that most users take for granted, like user presence, typing status, read receipts, and location sharing. It sends messages over your data connection and increases the size caps on photos and video sharing.

The current problem with RCS versus an over-the-top IM service is that users on different carriers are usually not able to talk to each other with RCS features enabled. The cell carriers fear being turned into "dumb pipes" and generally prefer proprietary services that give them customer lock-in. Naturally, they have resisted building an interoperable RCS system. Currently, the RCS landscape is fragmented, with RCS flavors like AT&T Advanced Messaging, Verizon Message+T-Mobile Advanced Messaging, and Sprint Enhanced Messaging.

Google got involved with RCS in 2015, when it acquired Jibe Mobile, a company that provides back-end RCS services to carriers. At the end of 2016, the GSMA published the "Universal Profile" spec, which was an agreed upon standard that would let the various carrier RCS implementations talk to each other. Google then started pushing carriers to adopt "Google Jibe" as an end-to-end RCS service, where Google could provide the RCS network, the cloud infrastructure, and the end-user clients. Android's default SMS app, Android Messages, was made to support this new standard.

RCS-powered “Chat”: Carrier-dependent messaging

  • The Verge scored a few screenshots of what the future Android Messaging client will look like. Here's the basic messaging interface.

  • Here's the desktop website, which requires scanning a QR code with your phone.

  • Smart Replies, a favorite feature of Google Allo and Android P, are here, too.

  • Group chat.

As part of this renewed RCS push, The Verge reports that Google is putting more resources (including the Allo team) into Android Messages, and RCS will be rebranded into a new service called "Chat." Not "Google Chat," because this is RCS, which is a carrier-controlled standard. RCS will just be rebranded to "Chat."

Being carrier-controlled comes with a number of downsides. First, Chat will need your individual carrier to support Universal Profile to work. Over 55 carriers—including the big four in the US—have "committed" to eventually support RCS, but no timeframe is included in that commitment. In the US, only Sprint has Universal Profile up and running right now. T-Mobile has promised a "Q2 2018" rollout, while Verizon and AT&T have so far declined to give a time frame. (This worldwide Universal Profile tracker is a great resource.) There's also no one single client for RCS. Google's RCS client is Android Messages, while Samsung phones come with a Samsung RCS app. Also, no one knows if Apple will support RCS on the iPhone.

Another big downside of carrier control is no end-to-end encryption. The Verge notes that Google's RCS service will follow the same legal intercept standards as SMS. Nearly all of Google's competition—like iMessage, WhatsApp, Facebook Messenger, Signal, and Telegram—supports end-to-end encryption.

Google's revamped Android Messages app will include old Allo features, like integration with the Google Assistant, GIF search, and smart replies. Android Messages is already an SMS app, so if your friends aren't on an RCS carrier, you'll still be able to send them a regular SMS message. SMS support will be a big improvement over Allo.

Messages will also get a desktop client, but it unfortunately sounds a lot like Allo's awful Web client. The Verge got to try an Android Messages Web client that, like Allo, paired to your phone through a QR code instead of a Google account. These QR-code powered systems typically mean you'll only allowed be logged into one device at a time, and if your phone dies, you can't text anyone. The "desktop client" is also only a webpage, so it won't run in the background the way Hangouts and other IM apps can.

Carriers versus consumers

Various Google execs have been asked numerous times why Google doesn't just build an iMessage clone, and the answer that came back was always something along the lines of "We don't want to jeopardize our relationship with carriers." Carriers famously dislike many of the consumer-centric choices Apple makes with the iPhone, and building a quality, non-SMS messaging solution was one of those choices. For Google, keeping carriers happy so they run Android and Google services on nearly every non-Apple device is far more important than rocking the boat with a competitive messaging app. The plan this year, apparently, is to try to strike a happy medium with the carriers.

Like Google Allo, Chat will start far, far behind the competition at launch and will need to move quickly to catch up. If it catches up—if that's even possible—it needs to surpass the entrenched messaging services and be so much better that users are willing to switch. It seems like it will be especially tough to accomplish this while being hamstrung by the world's cellular carriers. Just making RCS actually work across carriers is a huge challenge, and it would only result in a very basic messaging system that can be matched by every other chat app in existence. Plus, the lack of end-to-end encryption already makes Google's Chat plans inferior to other services in many people's eyes.

With all these challenges ahead of it, can Google turn RCS into something worth using? If Google's history with past messaging apps is any indication, the answer is "no."

Read the whole story
emdeesee
6 days ago
reply
Well, that didn't take long.
Lincoln, NE
Share this story
Delete

Java Future Release Notices

1 Comment

Public updates for Oracle Java SE 8 will remain available for individual, personal use through at least the end of 2020. 

Public updates for Oracle Java SE 8 released after January 2019 will not be available for business, commercial or production use without a commercial license.

If you are a CONSUMER using Java for individual, personal use, you will continue to have the same access to Oracle Java SE 8 updates as you do today through at least the end of 2020. In most instances, the Java-based applications you run are licensed separately by a company other than Oracle (for example, games you play on your PC are likely developed by a gaming company). These applications may run on the Java platform and be dependent on Oracle Java SE 8 updates beyond 2020. Accordingly, Oracle recommends you contact your application provider for details on how they plan to continue to provide application support to you.

If you are a DEVELOPER, Oracle recommends you review the roadmap information for Java SE 8 and beyond and take appropriate action depending on the type of application you develop and your distribution model.

If you are acting on behalf of an ENTERPRISE, Oracle recommends you review the roadmap information for Java SE 8 and beyond and begin to assess your ongoing Java support requirements in order to migrate to a later release or obtain a commercial license, as appropriate, on a timely basis. Oracle customers who use Java SE as part of another Oracle product may continue to have access to Oracle Java SE 8 updates beyond 2019 for those Oracle products, see this My Oracle Support (MOS) note for more information.

Further information is available on these sites:



Read the whole story
emdeesee
7 days ago
reply
And this is why I prefer Common Lisp over Clojure.

I know you were wondering.
Lincoln, NE
Share this story
Delete

12 Emacs Keybindings Worth Learning

1 Comment

After spending a bit of time learning Emacs, I’ve found it has a widespread compatibility with a lot of the basic movement and editing commands. Spending a bit of time learning these commands can make you more effective in a variety of places, even if you don’t use Emacs as your preferred editor.

Useful Emacs Keybindings

The most basic bindings that I’ll cover here are shortcuts that let you move your cursor around and delete text. On macOS, it’s worth noting that the Option key is the Meta key. On Windows, this is usually the Alt key.

Moving and deleting by words

FunctionKeyboard shortcutAlternative in macOS
Move forward one characterControl-f
Move backward one characterControl-b
Delete forward from the cursorControl-d
Move forward one wordMeta-fControl-Option-f
Move backward one wordMeta-bControl-Option-b
Delete the last wordMeta-Delete
Delete the next word (forward)Meta-d

Moving and deleting by lines

FunctionKeyboard shortcutAlternative in macOS
Move up one lineControl-p
Move down one lineControl-n
Move to the beginning of the lineControl-a
Move to the end of the lineControl-e
Delete to the end of the lineControl-k

Where Do They Work?

It’s quite likely that a lot of the software you interact with as a developer has support for these commands hidden away. For example, all of these should work out-of-the box on your shell and most programs, especially if they use the GNU readline library.

As it turns out, many of the default Emacs commands are also implemented by the text editing system built into macOS. This makes them available pretty much anywhere you’re entering text, even in your browser’s URL bar or when you’re composing an email.

Given Emacs’ long and influential history, I’ve found that you can just try to use them somewhere, and you will often find success.

Some Example Use Cases

I often find myself using these shortcuts for scenarios such as:

  • Quickly deleting the last word I (mis)typed using M-del, before retyping it
  • Jumping back a few words on the command line so I can change or insert an argument to the program before I invoke it
  • Abandoning and deleting the line I’ve been typing with C-a C-k

Why Not VI Bindings?

I used to be one of those people who enabled VI bindings in my shell. For short editing tasks, I found the friction to be too much. It’s a lot easier to press M-b a couple times and resume typing, without the mental overhead of modality. Dealing with modality at the shell can often be quite jarring.

Beyond this, Emacs bindings are available in a lot more places.

Next Steps

Did you know there’s also a command for transposing words? It’s M-t. This one can be handy for switching arguments around at the command line. There are a lot more Emacs commands that are commonly implemented. To learn more, I suggest reading the Emacs or the GNU Readline documentation.

If you’ve ever found yourself using the arrow keys to navigate text at the command line slowly, character by character, I hope you’ll have found this post useful.

The post 12 Emacs Keybindings Worth Learning appeared first on Atomic Spin.

Related Stories

Read the whole story
emdeesee
7 days ago
reply
Come in. Welcome to the church of Emacs.
Lincoln, NE
Share this story
Delete

Tens of thousands of Facebook accounts compromised in days by malware

1 Comment

Facebook's guidelines visually sum up "offensive things" with this blue text balloon. Meaning, it doesn't resemble a "fully exposed buttock."

Criminals have compromised tens of thousands of Facebook accounts in the past few days using malware that masquerades as a paint program for relieving stress.

"Relieve Stress Paint" is available through a domain that uses Unicode representation to show up as <a href="http://aol.net" rel="nofollow">aol.net</a> on search engines and in emails, researchers from security firm Radware said in a post published Wednesday morning. (This query showed the trojan was also available on a domain that was designed to appear as <a href="http://picc.com" rel="nofollow">picc.com</a>.) The researchers suspect the malware is being promoted in spam emails.

Once installed, the malware acts as a legitimate paint program that changes colors and line size with each user click. Behind the scenes, it copies Chrome data that stores cookies and any saved passwords for previously accessed Facebook accounts.

Radware

"Stresspaint," as Radware has dubbed the hidden program, continues to copy the Facebook credentials each time a target opens Relieve Stress Paint and each time the computer restarts. The data is sent to a command-and-control server. Radware researchers were able to access the command server's interface, which showed that more than 40,000 computers had been infected by the malware in recent days. In the process, tens of thousands of Facebook accounts were compromised. The interface also compiled any payment details tied to an account, the number of friends the account had, and whether the account was used to manage a page.

The interface also included a section for viewing credentials for victims' Amazon accounts. It was empty, leading Radware to suspect the attackers hadn't yet enabled code that would actually compromise those accounts. Radware also detected another variant of the malware and saw an indication of it in the control panel.

The malware was designed to copy the credentials in a way that wouldn't be detected by antivirus programs. The copying process, for instance, remained active for less than one minute. The malware didn't steal general credentials, and it copied cookies and saved passwords by querying copies of the original cookies and LoginData files rather than through other means.

It remains unclear precisely what the attackers did with data they obtained. Possibilities include selling the data in criminal forums, using it for identity theft or espionage, or using the payment data to buy goods or services on e-commerce sites.

More than five days earlier this week, the malware managed to infect nearly 34,000 computers in two dozen countries.

Radware

Since then, more than 6,000 more infections have occurred.

Anyone who may have been infected by this malware should immediately change their password and should also check the security and login section of their Facebook settings for logins by unrecognized computers. It's always a good idea to protect accounts with multifactor authentication, but it's not yet clear if that protection would have prevented attackers in this campaign from accessing compromised accounts. Because the malware stole both passwords and cookies, it's possible the cookies allowed the attackers to bypass the protection.

In a statement, Facebook officials wrote: "We are investigating these malware findings and we are taking steps to help protect and notify those who are impacted." A spokesman said it wasn't yet clear what effect the attacks had on accounts protected by multifactor authentication.

This ability to infect 40,000 users and compromise tens of thousands of accounts indicates the malware was developed professionally. It wouldn't be surprising to see this group strike again. Radware's blog post is here.

Read the whole story
emdeesee
7 days ago
reply
Oh, Facebook...
Lincoln, NE
Share this story
Delete

The Shape of Code » The C++ committee has taken off its ball and chain

1 Comment

A step change in the approach to updates and additions to the C++ Standard occurred at the recent WG21 meeting, or rather a change that has been kind of going on for a few meetings has been documented and discussed. Two bullet points at the start of “C++ Stability, Velocity, and Deployment Plans [R2]”, grab reader’s attention:

● Is C++ a language of exciting new features?
● Is C++ a language known for great stability over a long period?

followed by the proposal (which was agreed at the meeting): “The Committee should be willing to consider the design / quality of proposals even if they may cause a change in behavior or failure to compile for existing code.”

We have had 30 years of C++/C compatibility (ok, there have been some nibbling around the edges over the last 15 years). A remarkable achievement, thanks to Bjarne Stroustrup over 30+ years and 64 full-week standards’ meetings (also, Tom Plum and Bill Plauger were engaged in shuttle diplomacy between WG14 and WG21).

The C/C++ superset/different issue has a long history.

In the late 1980s SC22 (the top-level ISO committee for programming languages) asked WG14 (the C committee) whether a standard should be created for C++, and if so did WG14 want to create it. WG14 considered the matter at its April 1989 meeting, and replied that in its view a standard for C++ was worth considering, but that the C committee were not the people to do it.

In 1990, SC22 started a study group to look into whether a working group for C++ should be created and in the U.S. X3 (the ANSI committee responsible for Information processing systems) set up X3J16. The showdown meeting of what would become WG21, was held in London, March 1992 (the only ISO C++ meeting I have attended).

The X3J16 people were in London for the ISO meeting, which was heated at times. The two public positions were: 1) work should start on a standard for C++, 2) C++ was not yet mature enough for work to start on a standard.

The, not so public, reason given for wanting to start work on a standard was to stop, or at least slow down, changes to the language. New releases, rumored and/or actual, of Cfront were frequent (in a pre-Internet time sense). Writing large applications in a version of C++ that was replaced with something sightly different six months later had developers in large companies pulling their hair out.

You might have thought that compiler vendors would be happy for the language to be changing on a regular basis; changes provide an incentive for users to pay for compiler upgrades. In practice the changes were so significant that major rework was needed by somebody who knew what they were doing, i.e., expensive people had to be paid; vendors were more used to putting effort into marketing minor updates. It was claimed that implementing a C++ compiler required seven times the effort of implementing a C compiler. I have no idea how true this claim might have been (it might have been one vendor’s approximate experience). In the 1980s everybody and his dog had their own C compiler and most of those who had tried, had run into a brick wall trying to implement a C++ compiler.

The stop/slow down changing C++ vs. let C++ “fulfill its destiny” (a rallying call from the AT&T rep, which the whole room cheered) finally got voted on; the study group became a WG (I cannot tell you the numbers; the meeting minutes are not online and I cannot find a paper copy {we had those until the mid/late-90s}).

The creation of WG21 did not have the intended effect (slowing down changes to the language); Stroustrup joined the committee and C++ evolution continued apace. However, from the developers’ perspective language change did slow down; Cfront changes stopped because its code was collapsing under its own evolutionary weight and usable C++ compilers became available from other vendors (in the early days, Zortech C++ was a major boost to the spread of usage).

The last WG21 meeting had 140 people on the attendance list; they were not all bored consultants looking for a creative outlet (i.e., exciting new features), but I’m sure many would be happy to drop the ball-and-chain (otherwise known as C compatibility).

I think there will be lots of proposals that will break C compatibility in one way or another and some will make it into a published standard. The claim will be that the changes will make life easier for future C++ developers (a claim made by proponents of every language, for which there is zero empirical evidence). The only way of finding out whether a change has long term benefit is to wait a long time and see what happens.

The interesting question is how C++ compiler vendors will react to breaking changes in the language standard. There are not many production compilers out there these days, i.e., not a lot of competition. What incentive does a compiler vendor have to release a version of their compiler that will likely break existing code? Compiler validation, against a standard, is now history.

If WG21 make too many breaking changes, they could find C++ vendors ignoring them and developers asking whether the ISO C++ standards’ committee is past its sell by date.

Read the whole story
emdeesee
8 days ago
reply
"May you live in interesting times."

Well, I mean, for some value of interesting.
Lincoln, NE
Share this story
Delete
Next Page of Stories