Gary Robinson's Rants

The Wild World of NFTs

You may have heard about an artist named Beeple selling an "NFT" for $69 million a few weeks ago. NFT's are "non-fungible tokens," a definition that may not explain much! In this piece, I will try and provide a birds-eye view introduction to this wild new world. 

If you read some of the recent articles about the NFTs, you'll see mention of "blockchains." Skipping all technicalities, the important thing about blockchains—the thing that makes them so useful—is that many, many computers are involved, working together, to store information. There are vast numbers of copies of that information. The fact that there are so many computers involved means that if the owner of one of them, or even a sizable group of them, wants to cheat by changing the stored information, he (or they) can't. This is because a larger number of computers still have the correct information and will refuse to accept the change.[0]

For instance, if the information that you own a particular amount of digital money is stored in a blockchain, nobody can change that information. You own it and can trust that you will continue to own it.

Now, digital money is "fungible." One digital coin is equivalent to another, the same way any particular dollar bill is equivalent to any other. So digital money can serve the same role as dollar bills in online transactions. If a merchant accepts one person's Bitcoin, every other person's Bitcoin is identical, and the merchant will accept it.

But "non-fungible" pieces of information can also be stored in the blockchain, such that there is only one and no other one is equivalent. Or there could be a set of such pieces of information with a limited number. If the piece of information is a "non-fungible token" representing a work of art, then it's helpful that information can be stored in it specifying one person as the owner.[3] And nothing can change that because it would mean messing with more computers than it's possible to mess with.

So, provenance is established. The record of provenance is stored in the blockchain. In the ordinary world, the provenance of the Mona Lisa is well-established. There's probably paperwork stored somewhere in the Louvre going back to da Vinci. But everybody agrees that the one in the Louvre is the original. Now, suppose somebody makes a copy that is so exact that even the best experts can't distinguish it from the original. The copy would nevertheless have little value. It's the provenance that matters for value.

Everybody trusts the provenance of the Mona Lisa that's in the Louvre. But everybody can also trust the provenance of an artwork represented by a non-fungible token in a blockchain.

Now, some people are using NFTs to represent the provenance of physical works of art; that information is just as secure there as it would be in a vault in the Louvre. So there's a reason to do that. But I don't personally think that, for most works of art on the marketplace, there is serious question about their provenance such that that's the most important use for NFT's.

My personal opinion is that the primary art-related value is for digital artworks, where every copy is absolutely identical to the original and there is no hope of telling them apart except for information stored somewhere that says who owns it. And there's no better place to store that information than on a blockchain. And there are services out there such that it is trivially easy to store that information there.

Why would anybody want to buy digital art? With traditional art, you can hang it on a wall or put it on a table and see it whenever you want. But with digital art, you can see it whenever you want to; it's just in your computer. For instance, it could come up whenever you're not working and take over your computer screen through "screensaver" functionality.

But I think their value is also analogous to things like baseball cards. For reasons having nothing to do with the physical characteristics of a cardboard card, certain rare ones, such as early Mickey Mantle cards, become very valuable over time. People don't hang them on a wall for their aesthetic virtues. They just want to own them because they're both rare and significant, and have value due to how rare and significant they are.

That's what happened with the Beeple NFT that sold for $69 million a few weeks ago.[1] It's a digital image. But because the artist had notoriety by the time Christie's auctioned it, and because the auctioned image contained images of earlier works of his for each day from an early point in his career, it was unique. In that way, it was analogous to a rookie season Mickey Mantle card. So it sold for a tremendous amount of money.

But another way I think NFT artworks will be valuable in the future is with "digital canvases" such as the Meural[2]. You hang them on the wall as if they're paintings. Such canvases can be beautifully colorful and can display any work of art. You see a Van Gogh in the frame at the page linked at [2]. But of course, Van Goghs lose something in that kind of representation. The translation to digital form can't retain every nuance of a physical work.

Still, a frame like that has the advantage that beautiful artworks can rotate through it... so you can have Van Gogh during the day and a Picasso at night if you want. Or a different great painting every 5 minutes.

But now consider artworks that are created specifically for a digital context. I visited a museum recently which was showing the works of an artist who has been well-known for many years but had started working on an iPad. There were many works of his being displayed in digital frames on the walls, all of which were created on that iPad. They looked great. I felt that they were real art, and worth displaying on one's wall in a digital frame. And provenance would matter: for a given work, you could own the only NFT for that work.[4] If other people showed the same image on their walls, it would be analogous to you having an original physical work by that artist, from the period when he still used a canvas and brushes, and others showing extremely well-done copies. Only yours would have the value associated with that artist's work.

The result of all this is that the world of NFTs provides a new avenue for artists to create and sell their work. It has different characteristics from the traditional art world, such as eliminating the need for artists to convince gallery owners to display their works. (However, other means will then be necessary to develop the awareness of potential buyers, and those means are being developed now by entrepreneurs.)

 

[0] In reality, nothing is perfect. People have had digital money stolen. Also, there are nuances such as "Proof of Work" vs. "Proof of Stake" that affect what roles all those different computers have. I am trying to be as high-level here as possible to communicate only the absolute basics.

[1] https://www.nytimes.com/2021/03/11/arts/design/nft-auction-christies-beeple.html

[2] https://www.bloomingdales.com/shop/product/meural-winslow-digital-canvas

[3] Actually, the information is stored at an "address" on the blockchain; and the owner of a coin knows the address and keeps it secret. The fact that someone could discover the secret is one of the vulnerabilities by which one can steal digital money or NFTs. For instance, you might print out the address and keep it in a safety deposit box; somebody might break into the bank vault and get the information.

[4] An artist can also create the equivalent of limited edition prints by creating a fixed number of NFTs that are identical except for ownership information.

Git In Two Minutes (for a solo developer)

Inspired by “Git in 5 Minutes”, I decided to take things a step further, and create guide for git that takes even less time to get through. Of course, this is very minimalistic git! But it’s enough be useful for beginning solo developers, and provides a start from which you can grow. As far as I know, this post is the absolute record for minimalistic git guides on the web!  

In two minutes, there isn’t time to worry about a remote server, so this manner of using git is only appropriate for a solo developer who has a regular backup strategy in place for their hard drive. With 2-minute git, plus a backup strategy, you can confidently commit files and know that you can see changes or restore an earlier version if you need to.

Why does this even matter? Well, one of the most annoying and time-consuming experiences a developer can have is to realize that something that used to work no longer does. In such situations, simply being able to see changes and go back to an earlier version can be a huge help. Also, being able to go back gives you freedom to experiment with a new approach — there’s no problem experimenting because you can always go back.

When you have a chance, you should definitely learn about such features as staging and branching, and pushing and pulling to/from remote repositories. But what you’ll learn here will still be useful!

Note: When a filename is mentioned below, you can just as easily use a file path.

 

Getting set up to use git

We’re assuming you’re working in a directory. The first thing you should do is:

  git init

which initializes the directory for git use.

 

Telling git about your files

Now you have to tell git which files it should care about. If you have N files, you can do 

  git add <file1>  <file2> … <fileN>

to add them. Or if you want to add every file in the directory, you can do

  git add .

Committing changes

Next, we need to commit changes. Any time you want to commit changes to one or more files, do

  git commit <file1> <file2> … <fileN> -m "This is your commit message"

Or, to commit all files that have changed since the last commit:

  git commit -a -m "This is your commit message for all changed files"

Be sure to make your commit message contain enough of a description that you can figure out what version you want to go back to.

 

Viewing history

Now we need a way to see old versions are available. To see your commit messages along with each version’s “hash” (a number that refers to the version), you can use the following command to show them in a one-version-per-line output. 

  git log --pretty=oneline

That will give you output that looks like the following, showing each commit’s hash together with its commit message

  dbe28a0a1eba45d823d309cc3659069fc16297e3 4th version I wanted to commit
  13bbf385e6d1f94c7f11a4cdfa2a7688dfdd84f8 3rd
  a1696f671fb90dc8ea34645a6f851d0ab0152fc2 2nd version
  179e59467039c7a7b81f676297415c8e018542a0 first version

Note, you can also use

  git log

for a much more verbose output, with multiple lines per version, and you can use

  git log --pretty=oneline -- <filename>

 to view only the changes for a particular file. (Note the space after the second pair of dashes!)

 

Restoring an old version

To restore a file to an earlier version, you need to identify the version you want to restore. To restore the most recently committed version, just do:

  git checkout HEAD -- <filename>

To get back an earlier version, just use the first few characters of the hash (enough to uniquely distinguish it):

  git checkout <hash> -- <filename>

For example,

  git checkout 179e59467039 -- myfile

will revert my file to the contents of the file called myfile that are associated with the 179e59467039c7a7b81f676297415c8e018542a0 hash (in this case, the first committed version of the file).

 

Seeing changes

You usually won’t want to retrieve an old version of a file without first examining the changes it contains! To see a list of the changes between the current file and the most recently committed one, you use the fact that HEAD represents the most recent commit:

  git diff HEAD -- <filename>

Alternatively, see a list of differences between the current version of a file and a historical one, you refer to the historical version’s hash:

  git diff <hash> -- <filename>

You can also compare two historical versions:

  git diff <hash1>  <hash2> -- <filename>

Finally, to see a list of the changes you’ve made since your last commit across all files, simply do:

  git diff 

Note: all the diff variants shown above put the results into a pager. You can page through using the space bar, and quit with q. If you don’t want to use the pager, add -P, like:

  git -P diff HEAD -- <filename>

 

Undoing a bad commit

More often than I care to admit, I've committed a change and then found that there was an error in either the commit message or in the code itself. I don't see any need to keep that error for posterity. So here's how to undo the commit and the related commit message:

  git reset HEAD^ 

If the only problem is in the commit message itself, you can replace it with:

  git commit --amend -m "Replacement commit message"

 

One more thing – optional – may add another minute

While you can get a lot of benefit using just the features above, here's one more thing you'll find to be useful. If you don't want to bother with it now, don't – try it another time.

Sometimes, you're not sure what files have changed. To find out, you can do:

  git status 

That'll generate a list of files and their statuses. For example, a file that hasn't been "git add"-ed will be listed as untracked; if it's a file you care about, you should add it.

The reason I consider this command "optional" in a two-minute guide is that it can be a little unwieldy. It can list a lot of files you don't care about. For instance, if you're programming in Python, it'll show the compiled .pyc files that Python generates. And you'll probably want to do something about that.

To fix it, you need to create a file called .gitignore in your project directory. For instance, if you're working on a project in Python 2.x, you'll probably want it to contain (at least):

  .pyc

Notice that .gitignore understands the * wildcard. And if you want to hide an entire directory, you append the folder name with a slash. For instance you're working in Python 3.x, the compiled files go in a directory called __pycache__, so you'll want the following in your .gitignore:

  __pycache__/ 

 

And that’s it! Just keep this guide handy.

That’s all you need to know to get started with git, as long as you have a regular backup strategy for your hard drive. If you don’t want to memorize anything, just keep this guide bookmarked and you’ll be able to commit, compare versions, and get back old versions without any trouble!

Remember, this guide is literally as minimalistic as you can possibly get in order to do something useful with git. For powerful features like branching, staging, and sharing with others via a remote server, be sure to move on to Git In Five Minutes and even (?!) longer git guides when you have a chance!

 

[Update Aug 6, 2022: added the entry for undoing a commit.

Update Jan 2, 2017: added the use of HEAD in restoring file versions.

Update September 7, 2015: added two more ways of seeing changes.

Update September 20, 2015: for some reason the optional section on git status and .gitignore disappeared at some point. So I put it back! Also rewrote the diff section to put the HEAD version first.]

Non-blocking raw_input for Python

I needed a way to allow a raw_input() call to time out. In case it's useful to anyone, I wrote this solution which works under Unix-like OS's.

Simply call nonBlockingRawInput("your prompt text", n) where n is the number of seconds you would like the prompt to wait until it times out. If it does time out, it will return with an empty string.

import signal

class AlarmException(Exception):
    pass

def alarmHandler(signum, frame):
    raise AlarmException

def nonBlockingRawInput(prompt='', timeout=20):
    signal.signal(signal.SIGALRM, alarmHandler)
    signal.alarm(timeout)
    try:
        text = raw_input(prompt)
        signal.alarm(0)
        return text
    except AlarmException:
        print '\nPrompt timeout. Continuing...'
    signal.signal(signal.SIGALRM, signal.SIG_IGN)
    return ''

[Edited Aug. 30, 2010 to fix a typo in the function name and generally improve formatting]

[Edited Feb 1, 2022 to add a tad more explanation, since the comments indicate people are still finding this!]

Snow Leopard Guest User data loss bug

I've seen a number of mentions today of a bug that can cause a Snow Leopard user to lose all their data:

The problem appears to manifest itself on machines which had the Guest account option enabled under Leopard and were subsequently upgraded to Snow Leopard. Users booting their machines have reported that upon start-up, they have been logged into the Guest account. Upon switching to their regular account, the affected users have been finding all of their user data missing and unrecoverable except from a backup. [MacRumors.]

One user reports a way to recover the lost data. Since it's buried in a discussion thread, I'm reproducing it here (also fixing a typo pointed out by a reader of this blog):

The files were still in /Users,
recovery was not too difficult.

1) su in terminal
2) mv username username.old
3) create account username
4) mv username username.new
5) mv username.old username
6) chown -R username username

I don't know whether it's a general fix. If you run into the bug and decide to try this solution, feel free to post your experience in the comments section!

FlyFi.com upgrade

We've made a substantial upgrade to the look and feel of our Flyfi.com web site. The site does a lot, and this release has been geared toward making the functionality more readily apparent and easier to use.

FlyFi Community Playlist

If you're a Facebook user, you might want to check out my company's FlyFi Community Playlist app which lets a Facebook community collaborate on a playlist... but it's more than a playlist because it also provides tracks related to the manually entered ones.

A fair number of the tracks are legally downladable free MP3's, from superb artists like Randy Newman (one of my personal top 5 artists), Ani DiFranco, Suzanne Vega, Dar Williams, and many others.

Correction re singletons

The source code link presented at the main post for my singleton mixin classes was bad until now. It pointed to an earlier version that didn't have thread safety or various other improvements. Sorry.

Even more singleton improvements

singletonmixin now deals with cases where you want to be able to include args in calls to S.getInstance() even after the initial instantiation.

More singleton improvements

Based on internal work and feedback appearing in comments on this blog, I've updated the Python singleton class I posted way back in 2004. That earlier post remains the place to get the code and place any further comments.

It now handles keyword arguments, and is threadsafe for singleton creation.

Iran

If you've been following developments in Iran, and particularly the Internet's essential role in reporting (and supporting) events, I don't have much to add.

If you haven't, I strongly suggest you go to Andrew Sullivan's blog and starting following him now -- as well taking a bit of time to look through his posts from the last couple of days. He's been doing a wonderful job. Far better than any mainstream news outlet, with the possible exception of the NY Times' Lede. (Although the Lede doesn't present as much detail and analysis as Sullivan does -- with the help of his readers and well-chosen links to other sources.)

One of Sullivan's readers sums up the key role Twitter is coming to play:

Ahmadinejad's and Khamenei's websites were taken down yesterday - I saw the latter go down within a couple of minutes because of a DDOS attack organised via Twitter. @StopAhmadi is a good source for tweets on this. The other important use of Twitter has been distribution of proxy addresses via Twitter. This would be how most video and pictures of today's rally have gotten out.

One amazing thing is that it seems at least conceivable that the protests would not have been as successful as they currently appear to be if Twitter didn't exist.

Sullivan suggests wearing green in support of the protesters. I think that's a great idea.