Sutor said they need to focus on usability, stability, security, reliability, performance, with some cool thrown in, as well… I think making it a complete drop-in replacement is a dead-end strategy.
Sutor’s speech on desktop Linux has inspired me. Accordingly, I’d like to present the…
Bob Sutor Guide to Running a Marathon
Overall fitness is important on race day. You’ll need to focus on your endurance, your heart, your leg muscles, your feet, your abs, your waist, and some arms thrown in too.
Running form is important on race day. You’ll need to focus on your breathing, your leg motion, your arm movements, the length of your strides, and some pacing practice thrown in too.
The training routine is important on race day. You’ll need to focus on finding other runners to practice with, self discipline, getting a top personal trainer, and some knowledge of the track thrown in too.
Don’t try and win the race. That’s a dead-end strategy.
You’ll note that Bob left out “compatibility” from his list of things to focus on. A strange omission, coming from the company that witnessed IBM Compatible computers dominate the PC industry without actually being sold by IBM. Compatibility then meant being able to run Microsoft with the same hardware and software. It still does today.
We’re pretty good at hardware. My girlfriend got confused by the manual that came with her latest printer: it gave 12 steps for Windows, another 12 for Mac, and then an additional 6 for both. There were no Ubuntu instructions. Turns out all she had to do was plug it in, the first thing she would have tried if there wasn’t a scary manual making her think printer setup required some sort of shaman dance. This is a good problem to have, although having to tell your girlfriend to stop shaking her hips at the printer is perhaps an even better problem to have.
Winning
Hardware works, but we haven’t won yet. We could make every single graphics card, printer, digital camera, and music player work out of the box flawlessly and we’d still miss the market completely. We wouldn’t actually be compatible. What we have is a software problem. That’s why I work on Wine.
IBM management has never really believed in Wine as a technology, even though their own engineers find it useful. Jeremy White has even said that IBM Managers weren’t very helpful.
For my part, I’m going to ignore IBM’s failed attempt at leadership and focus on what actually matters: making things work for users. Only if we become compatible can we be at least as good. Then people give us a try, and notice we’re actually better. That’s when we win.
Here, let me highlight it for you in case you missed it.
That’s at least five different places where we tell the user to restart. This is, as I would say to my students, a redundant use of redundancy.
I think we can give our users a bit more credit here. Consider this version:
That pretty much says the same thing, with no text at all. But even that may be more than is needed. Suppose you just ran update manager, installed a system update, and then saw this:
For those of us who’ve used update manager before, this isn’t much of a puzzle to figure out. The computer is asking for permission to do something, and since we just ran update manager it’s probably a system restart.
What’s important
Whoever wrote this dialog obviously wanted to get across the message that a restart was about to happen. Well, they succeeded, but now we have a problem of wordiness. This dialog doesn’t just say restart, it also says this:
So let’s use the example above and improve this dialog a bit, emphasizing what’s actually important:
Not bad isn’t it? The important bits are in there, and they’re no longer lost within a 3 paragraph beast. Let’s try and humanize it a bit without losing these advantages.
Same message, much more readable. Removing the title is an interesting change: now it doesn’t feel like reading a document for homework, but instead something predictable and very easy to understand. This is just a first draft, of course, but since it’s something literally millions of people will see, I think it’s worth taking a bit of time to get it right.
It was a few months ago, however the videos from the Ubuntu Developer Summit have finally been made available to me in a streamable form. This was a short, unrehearsed talk I gave to briefly convince the Ubuntu developer community that Wine isn’t a threat to free software, but rather an important tool that makes migration to a free platform possible.
Advice for those giving presentations
After rewatching the above, I can say the following things with confidence.
The fewer words on your slides, the better.
Bullet points aren’t short enough.
If you start with a borrowed joke it will come off awkward.
Unless you can’t be funny, write your own jokes.
Never let someone control the slides for you.
Wine Bug Day this Sunday
Now, while I have your attention, how about you participate in the next Wine Bug Day for this Sunday? It’s very simple – mostly we’re just downloading random games and playing them for a bit to see if a bug is still there. And it all helps Wine development, so it’s good. Check out the wiki page and join us!
One of my self-appointed duties has been cleaning up the Winehq.org web site. It was, in short, failing miserably at its purpose. Users would go to the website and still not really know what the Wine project was about. If they read a lot of words, they might be able to learn what the program does and where to download it, but if they read too much they’d land on a status page that hadn’t been updated since 2004.
Documentation that makes the user feel less informed after reading it is a very special kind of awful.
If everything is broken, start with what’s most visible
The two most popular pages were the front page and the About page. They seemed like simple enough targets. The front page was just a handful of links and large, friendly buttons, however even here there was substantial room for improvement. The key is to use affirmative verbs to imply what happens when the user clicks: Overview of Wine features becomes Learn about the Wine project. By simply changing a subtitle, we’ve already given the reader confidence and come off far more sincere.
Unfortunately, if the user actually clicked the About page, they would see this:
Wine is a translation layer (a program loader) capable of running Windows applications on native programs Windows 3.1 ports for other Unixes bug tracker Win32. Here’s a link to 7 even longer articles.
It went on for 4 paragraphs – that’s an awful lot of text to have on an about page. We needed to start from scratch, and that includes figuring out what the page is actually supposed to do:
Goals of an About page:
Tell them that Wine can run their Windows programs on Linux (or Mac)
Not make it sound like Wine is complicated enough to require shaman dances
Point users to AppDB if they want to know about a particular program
Encourage users who are still on Windows that migrating to Linux is ok
Be concise enough to read
Explain the open source nature of the project, and the role of Codeweavers
I worked on it for a good number of hours. It’s surprising how long it takes to do focused writing, but when you do it right you end up saying more than twice as much in half the words. I’m quite happy with the new text on the About page, although now there’s a new problem: the text is so short it looks really flat and wide.
This is a good problem to have. The traditional answer for long text is to collapse it into a narrow column. If you read a Paul Graham essay, for instance, you’ll find that 3/4 of the page is whitespace on a typical widescreen monitor. For an About page, this is the perfect place for a picture. I don’t, however, have one just yet.
Can you think of a picture that sums up what Wine is about?
Announcing plans for a second Wine Bug Day
On another note, since the last Wine Bug Day was so successful, I’ve decided to do the exact same thing again. I’m not yet certain of the time, however. I’ve heard feedback that a weekend might be better than a Monday, but I don’t really know. If you have experience with this sort of thing, please feel free to comment. Thank you, especially if you want to participate.
I want to help Wine development in any way I can. Sometimes this means putting on pants and discussing donating money to Wine with serious people. Sometimes it means using my charming personality to persuade promising programmers into becoming Wine developers. Sometimes, however, it’s about something larger: helping existing developers work more efficiently.
Engaging the community
While Wine has over 2 million users, we’re not particularly good at marshaling the community towards helping out. The Application Database, for instance, contains test reports that are frequently out of date and not particularly useful.
Getting good involvement from the community is not a trivial task. Users need some level of expertise and confidence before they can offer useful help to others. People need to suffer through reading the same question over and over again in mailing lists and forums before they’ll volunteer to write the answer into actual documentation.
This means the most important tools are those that make it easier for community members to build that confidence and contribute. We used to require users to submit patches to update the FAQ. This meant they had to grow neckbeards, put on wizard hats, and use terminal commands just to edit a text document. Unsurprisingly, the FAQ quickly became so out of date that it was outright harmful to read.
After some nagging, the FAQ was eventually moved from the source tree into a wiki. The barrier to contributing went from learning a version control system to clicking an edit button on a web page. After years of neglect, the FAQ became genuinely useful within a single month.
I want to give Wine coders more time to, well, code. That means less time wasted doing all the other annoying tasks in life. Although I can’t do their laundry or clean their bathrooms over the internet, I can help them spend less time sifting through Bugzilla.
Is it worth triaging bugs?
Wine, like all reasonable projects, is utterly swimming in bug reports. Fortunately, we’re not quite drowning in them – while thousands remain open, we’re triaging them at about the same rate as new ones are being added, barely keeping our head above water.
Let’s think for a moment about what a developer gets from a bug tracker:
If something is broken, they learn about it so they can solve it later
Developers can collaborate with eachother on a solution
If they need motivation they can feel happy that actual users would appreciate a fix
They can consider the difficulty and importance of different bugs to prioritize work
All this breaks down when there’s a ton of out of date or otherwise bad bug reports. Instead of a useful tool, the bug tracker feels like an obstacle. Eventually it ends up like graffiti in a big city: the problem becomes so huge that any individual effort spent fixing it feels like a waste.
Working together on a bug day
The idea of a bug day is to make it much easier for community members to triage bugs. You’re all doing it together, so there’s less a feeling of solitude even if you’re alone in your parents’ basement. If you’re unsure of something, you just ask someone in chat, building up a little confidence. If you don’t have bugzilla permissions, someone else will set a bug’s status to fixed for you right there, keeping the energy up. This makes the whole process actually kind of fun – so much so that people actually organize real life parties dedicated to bug triage.
That’s why bug days work – they help bugs get triaged in the same way that wikis help documents get written. You see the collaboration and progress right before your eyes, especially when you pick a particular set of bugs as a target. There’s an easily measured goal to start with, and everyone gets excited when the group hits 50 bugs for the first time. This even works when the bugs are a relatively easy subset: for Wine’s first bug day I decided to only target bugs with free downloads that hadn’t been checked in over 7 months.
Claiming victory
To be honest, this bug day wasn’t very well planned. I basically picked a day, threw together a forum thread and an email to the developer list, and then hoped for the best. I didn’t even blog about it. Somehow, amazingly, it was still an overwhelming success:
Our bug target search (bugs unchanged since January 1st with the download tag) started at 574 bugs. Now it’s down to 508. That’s 66 bugs that were either resolved, confirmed, or at least checked in on.
In the past two days there have been 30 bugs newly resolved. By comparison, over the previous 2 weeks before then there were only 16 bugs resolved.
I’m definitely going to repeat it again and make this a regular thing. The community really does help if you simply ask.
It’s not a good situation when the most common advice to users experiencing problems is “upgrade to the unstable betas”, but that’s the reality of Wine these days. It’s also a sure sign of a release getting stagnant – when developers are actively telling people not to use it.
That’s why I’ve made the latest Wine beta releases available for Ubuntu Karmic. All you have to do is install the Wine1.2 package. No, Wine 1.2 isn’t actually out yet (the package currently has v1.1.25). But, when Wine 1.2 is out, I can easily replace the beta version with an update, complete with official-sounding release notes and documentation that no one will ever read.
This approach is very similar to what we did during the Ubuntu 8.04 cycle. Firefox 3 wouldn’t be out in time, but if we shipped Firefox 2 then our users would be stuck with a crusty web browser. That’s a mean thing to do to users, so instead we gave them a relatively stable beta version of Firefox 3 and then issued an update after release. I did the same thing with Wine – Wine 1.0 wasn’t out yet, so I shipped a pretty good beta and then patched it to 1.0.
If only there were more frequent releases
Now, I’ve been advocating Wine 1.2 come out in time for the next Ubuntu release for over a year now, but the truth is that’s going to be about as effective as my campaign to get old people to wear their diapers on the outside. Stable releases don’t just happen on their own; they need good release management, and Wine doesn’t even have a release manager at this point. In short, there’s a very good chance Wine 1.2 won’t be out in time, and at this point the 1.0 branch is as crusted as Firefox 2 was.
In search of a release manager
Wine 1.0 took 15 years to come out (incidentally, this is about as long as it took for Duke Nukem to get cancelled). We seemed to be doing a lot of development, but never actually progressed towards a stable release. This all changed during Wineconf, when a confluence of angels inspired the Wine developers to select Dan Kegel as the 1.0 release manager. He did the job wonderfully, and Wine 1.0 actually released, to everyone‘s surprise. Even Linux Hater felt the need to comment.
Our mistake, however, was stopping there. Dan Kegel doesn’t have much time for Wine anymore, and last wineconf we didn’t pick a new release manager for 1.2. So the situation looks much like it did during those 15 years before Wine 1.0′s release: a bunch of developers doing their own thing while everyone else assumes that means picking our noses.
Wine still improves, of course, but without a stable release process users either run into frustrating beta regressions or try to use the old stable version only to discover that it doesn’t work half the time. This sounds awful, but it is a good problem to have – it means we’re a mature project with actual users who really want something they can depend on.
Volunteering for the job
So, I’ll be up front about this. Wine needs a new release manager, and if I can’t find a better person to do it I’m willing to tackle the job myself. Maybe that means personally setting up another server farm to run daily regression tests. Maybe it means going Indiana Jones on the darker parts of bugzilla only to discover that what I thought were useful patches were actually piles of scorpion-powered snakes.
I’ve already contacted Dan Kegel to ask for some pointers, and at his suggestion I’m going to take a much more active role in Wine bug triage. The release criterion wiki pages also need updating, and there’s likely going to be a lot of wrangling over the particulars of just what we as a project want Wine 1.2 to be. But that’s exactly the kind of discussion this community need to have – otherwise, a release simply won’t happen.
It started with a bug report that had been around since Ubuntu got started: Gnometris had a big Gnome foot logo on it, and most of our users didn’t know what that was. The suggestion was simple: replace it with a stylized Ubuntu logo, patch it in, and go on our merry way. A community member even volunteered a fantastic piece of art to go in its place. Simple, right?
Except, unfortunately, it wasn’t. You see, some people at Ubuntu are worried about derivatives: those Ubuntu-based distributions that use our code but aren’t actually Ubuntu. By putting a branded image in that derivatives have to remove, we make extra work for them.
So nothing happened. For years. We still had that ugly foot logo that had nothing to do with the game you were playing, and it was one of the first things users saw. But it wasn’t just Gnometris – it was solitaire too. Millions of hours of user time have been spent playing solitaire and staring at the ugly feet on the card backs. People would boot the Ubuntu LiveCD and feel like our games came straight out of 1995.
This bothered me. It was ugly, but even worse we were throwing away useful contributions. How much other useful stuff might we be throwing out, or even worse not making in the first place?
Enter UDS
The Ubuntu Developer Summit is a fantastic place for brainstorming ideas. You’re constantly surrounded by smart, passionate people. People who want to work with you on any and all things Ubuntu, from the moment you walk out of your hotel room for breakfast to the late hour you finally trudge off to sleep.
I think the branding-ubuntu package was my idea. I can never be sure, since I owe so much to the creative environment around me. I shouldn’t offend anyone by taking credit though; as you’ll see, my original design was stupid.
The overall idea seemed solid: put Ubuntu-branded replacement artwork, generated by the community, into a single branding-ubuntu package. Installing it would change the artwork, removing it would leave everything as before.
The original design required each branded application to have a small patch causing it to look for the branded artwork first (and prefer it.) This required modifying every program that we wanted to brand. All I had to do was dump a bunch of artwork in some folder, and then hope other people would change their applications to take advantage of it. Trivial for me, work for them – perhaps it wasn’t so stupid after all.
Community Leadership
Other than my three year old Gnometris background, I didn’t have any actual artwork to put into the package. We weren’t even installing Gnometris by default anymore. I made the package anyway. Even though it didn’t do anything, I decided to advertise and fish for community help. If I built it, perhaps they would come.
I wrote a few emails to our developer lists, rubbed a few shoulders on IRC, and reminded some of the people who mentioned it was a great idea at UDS. Importantly, I took charge, making it clear that all an artist had to do was make something nice and I’d handle including it personally.
Within a manner of days I had new, branded artwork for every game we ship. Now I had a whole lot of artwork, courtesy of MadsRH. The screenshots from a manual install were incredible – that blue foot was gone for good. All it took was a little initiative.
Unfortunately, those patches to use the branding hadn’t yet been written, and the upstream makers of Solitaire didn’t really want to do it. In retrospect this is completely understandable – it was their branding we were replacing, and it wasn’t clear to them why we weren’t just patching things on our end. Why should they care about our derivative worries?
The Real Solution
The real solution, of course, meant more work for me – but work that would actually get done. The branding package now renames existing artwork files and replaces them with symbolic links to its own (using some fancy shell scripts and the very obscure dpkg-diversions command). In short, it works elegantly.
So, now I’ve got yet another package under my stewardship. I started off just maintaining Wine five years ago, but now, in true open source fashion, I’ve been applying myself throughout the entire distro. Sometimes people refer to this as “scratching your own itches”, but in truth I don’t really play solitaire or use Wine that much. They’re not my itches – they’re the itches of millions of users. Those are real people, and that alone is reason enough for me to make things even just a tiny bit better.
It needs to be easier for community contributors to find out how they can help. We’ve had this discussion in Ubuntu before at past developer summits, and the ideas were generally things like “improve the participate link on the ubuntu.com front page.” Sorry, no one’s clicking that link anyway, and even if we did create an elaborate AI-powered survey system behind it we couldn’t possibly do better than an actual human providing an encouraging suggestion about what’s really needed.
Human responses
Over the past few months, at least five separate people have reached out to me personally asking about specific ways they could help. I’m happy to answer, of course, but this tells me that it’s not at all obvious for them to figure out on their own. Likely, there’s five more who never emailed me since it was too much of a hassle to talk to an internet stranger, even a blogger who IMs more than a 13 year old girl.
What’s needed, then, is just a simple encouragement of human interaction. The open source community is a strange concept to newcomers, even the computer-savvy. You really can just dive right in and start offering help wherever you’re useful, and developers will just treat it like it’s the most natural thing. Maybe you’re from another project, or deploying the software in a business, or just bored around the house. There’s no such thing as an imposter in open source.
Many people who aren’t used to this kind of openness find it intimidating – there are too many people, so it’s not obvious who to go to for help getting started. We try to have mentoring programs and the like, but these are for people who want to be serious developers solving big problems. Small problems don’t need serious developers – they need a serious amount of small help.
Practical things for getting small help
At the Developer Summit, we discussed the idea of using more helpful bug tags to help contributors find where they can help. Our goal isn’t to sort half a million launchpad bugs into forty tiers of type, importance, and difficulty – our goal is to get them fixed.
So, here are the brand new bug tags, based on a simple discussion from the developer summit:
Most bug trackers don’t really use tags like this because the system is obvious – if you’re looking at Wine’s bugzilla, then pretty much every bug in there really could be tagged “needs-coding-c”. Launchpad is different: we’ve got a whole mess of bugs, and half of them aren’t even in the code.
Now we’ve got a real answer to the question “I want to help, what can I do?” We just tag some bugs and say click the link: Launchpad will instantly tell them dozens of places where they’ll be useful. That’s important, as they’ll not only be able to help, but they’ll also see that they can fill a real need and feel good about themselves. Make contributing simple and rewarding, and users will do so eagerly.
I’ve just come back from the Ubuntu Developer Summit for 9.10, so I’ve got a flurry of things to do and follow up on. The first priority is to put together the community based on ideas generated during the sessions.
Ubuntu developer Facebook group:
Since it’s so easy to do, I just went ahead and made it myself. If you’re an Ubuntu developer, and you’re on Facebook, please go ahead and join. It should make networking easier than talking to a blank IRC channel or trolling Jorge Castro’s friend list.
Planet Feeds by Language rather than country:
This was an idea I had and brought up with Jorge in a hallway conversation. In Spanish, for example, there are separate Planet Ubuntu feeds for Argentina, Ecuador, Chile, and Colombia. Doubtlessly some content that users would like to read is being missed. Similarly, the guy who translates the Ubuntu news into Spanish doesn’t have a specific “all Spanish feeds” place to post it, so it ends up going into the main (otherwise English) feed.
Things get even dicier with mixed languages. Interesting English content published to the country feeds is often missing from the main feed. More worrisome, a multilingual country may have to be split into separate language-based content feeds anyway.
I understand the concept behind country-based planet feeds. There will likely still be a demand for local content anyway, so perhaps they shouldn’t go away. But language based feeds are still better – they should even be displayed in a list above the country-specific feeds. We are, after all, a global project.
I love Ubuntu video:
Jono Bacon suggested it would be nice if we had members from the community each submit small bits of content that could be compiled artistically into a kickass promotional video. One idea was to get a whole bunch of people in front of their webcams saying “I Love Ubuntu”. As soon as I figure out the best standard way to do this (cheese?), I’ll take the initiative and submit my version.
Bonus Karaoke:
Traditionally, the final night of the Ubuntu Developer Summit includes a party. This one featured Karaoke combined with barroom accoustics, tinny speakers, a cheap microphone, and cell phone video recordings. Combined, these should render this presentation by Canonical’s community organizers appropriately awful:
I did three renditions myself. I’m not a horrible singer when playing Rock Band, mainly due to practice. Still, you don’t want to watch this video.
aside: The bumper sticker above came from the 2008 US Presidential Elections, where Republicans supporting Governor Palin mocked Senator Obama’s experience as a community organizer.
aside to the aside: There was an even better looking bumper sticker that I would have shown and linked, however the website selling it went to very elaborate lengths using javascript and embedded flash to try and prevent me from copying the image. In other words, they paid a web developer a thousands of dollars to build a system that makes me give someone else free advertising.
There’s an argument about to occur at the Ubuntu Developer Summit. It’s come up before, it’s coming up now, and it will come up again later. This argument, cliched as it is, is about security vs usability.
Imagine you’re a user. One who just happens to have Wine installed on your system. And you double click an executable file. What happens?
You might expect it to open. That’s what Windows did. But then people ended up running programs they didn’t actually want to run – they were surprised when Olson_Twins_Nude.jpg.exe wasn’t a picture at all, and even more surprised to discover their computer could be more accurately described as on loan from Vlad the hackpaler’s discount botnet.
It wasn’t long before third party security software and, ultimately, Windows Vista started giving prompts to the user. Even Firefox felt the need to warn you that the movie you just downloaded was actually a program.
The unix approach to this was to require the user to give explicit permission for programs to run by embedding it into the filesystem – the execute bit. No one complained, mainly because there weren’t many programs to download and run outside of a command line.
Two things have since happened. First, we wrote an awful lot of interpreters that don’t care about the execute bit, like Java and Wine. More importantly, we finally made a Linux desktop that doesn’t suck. Now people actually want to download things, and they want to run them without having to open that shortcut to the terminal. So the debate is back. Now we have to figure out what to do when you click on those pesky .exe and .jar files.
For Wine, the issue was “solved” for 8.10 and 9.04 by making double clicking on a .exe file flat out broken – Ubuntu will try to open your program in Archive Manager, hit you with a shovel, and then give you a mysterious error about the shovel blade being the wrong curvature.
Well, that solution wasn’t good enough for me. I wanted to make Wine open the executables on double click since, well, that’s how you open executables. But the security guys, understandably, want to be really sure that a user actually meant to open the executable. This means some sort of dialog has to happen between the computer and the user when you double click the .exe file.
I figured that, since I know something about user interface design, I may as well design the dialog myself and minimize the damage. Here’s my second attempt:
Ok, that sucked. I said it was my second attempt, because my first attempt was to go with something a little more direct.
I stared at my pen board for a good 10 minutes. As it turns out, it’s a bit difficult to design a dialog that conforms to user expectations when you’re deliberately ignoring what they just told you.
That’s a bit better. We’ll skip the obvious question of why we didn’t do what we were asked, and instead act like it just has to be this way. Any explanation would take up a bunch of words users won’t read anyway, so let them mindlessly click on launch application and maybe we can hope they’ll forgive us when their computer blows up because they gave it permission to.
Or, we can remember that the whole point of this message is to remind the user that this is a program they’re launching. Let’s start by putting a Wine icon there instead of that generic warning label.
You might be wondering what that “Wine preferences” button’s doing there at the bottom. That was me thinking ahead a bit – maybe a user will want to disable this behavior somewhere, so maybe we’ll need to have a preference setting for that, and we might as well help them get there as soon as they’re frustrated enough to fix it. But now we’ve made three buttons, and the user has to make a decision and think a bit. Worse, if they actually used the middle button, they’d have to dig through a bunch of unrelated Wine preferences before finding what they want.
Here, we give them exactly what they want right there in the dialog. We act like it’s some sort of preference they had set, so now instead of wondering why the computer didn’t do what you wanted until you told it twice, you at least know this annoyance can be prevented in the future by simply unchecking the magic box.
But that sentence says something else too, more than the button ever could: it has the phrase “new applications” in it. It means we’re only showing this dialog for programs you’ve just downloaded. If you’ve already run them before, the damage is done, so we may as well just launch without asking the second time. And, get this, we can keep track of it all by using that silly execute bit. Turns out it’s useful after all.
But there’s one more major improvement we can make. Did you catch it?
That’s right. It’s a very slight difference in wording. Without thinking about it, we wrote the original dialog like a programmer, using programmer jargon. Prompting is exactly what we’re doing here, and it’s the exact word I’d use to describe this dialog in a spec, and it’s exactly the most inhuman thing to say. Two words turn this dialog into something an actual human being might enjoy – now, instead of ignoring their double clicking due to these wonky default preference settings, the computer is doing the user a favor. We’ve turned a robotic vending machine into a bellhop who asks, “sir, did you mean to leave this dollar here?” whenever you try to tip him.
So, now I’ve got a rough design for a dialog. It’s the least bad I can think of. But it’s better the damage came from me than the security team.
native programs 
