chipx86

Someone got mine (298387 -- I'll never forget) through a security flaw that they temporarily had. The attacker tried selling it back to me for $1000. Loved the low number, but didn't use it anymore outside of testing Gaim (used to be a developer on that), so.. RIP 298387.

I actually got in trouble more for leaving a Kindle and a game system in a bag on my last trip than on the previous trip when I accidentally had a utility knife in my bag's pocket.

I was sure I was about to be detained for the knife, but they simply told me I could leave it there or exit the security line and mail it back to my house for a $15 fee. I took that mailer option, walked out of the line unescorted with a knife, filled out a mailing form, put the knife in the bag, and went through security again.

This most recent trip, I checked carefully for knives before heading to SFO. When I entered the line, they were low on bins. I started taking things out and asked if I needed to remove the Kindle and game system. The TSA agent said I could leave them in, so I did. By the time I got to the other end, I was pulled aside and questioned, as they checked for any suspicious residue on the devices. They eventually handed me the devices back and escorted me to the beginning of the line, where I had to go through all over again, this time with the Kindle and game system in a bin.

Not to hijack the thread too much (I'm also very curious about the answer -- I'm one of the Review Board founders and these discussions always interest me), but we support TFS these days in Review Board by way of our Power Pack add-on product, if you'd like an alternative solution. I can talk to you more about this off this thread if it's at all interesting to you.

Along the lines of reading HackerNews, read TheDailyWTF.com on occasion. It's fun and entertaining, but that's not why I'm recommending it. A lot of the bad code, bad error messages, bad designs, etc. were not necessarily done by someone _incompetent_, but rather people who are simply inexperienced in one way or another, or were in a rush to meet a deadline and weren't careful.

(At a former company, working in a team full of very strong engineers, we still found one dialog box of ours end up on that site once, and the issue it demonstrated led us to a bug in the code.)

If you start seeing things on there that look like something you'd have done, don't beat yourself up over it, but learn why those are WTFs and re-evaluate how you're writing code/designing software.

Back when Palm was up for sale, I was hoping beyond hope that Facebook would take an interest in getting into the hardware business (this is back when they were pushing for Facebook-specific app development more), decide to buy a phone manufacturer, and choose Palm, renaming the company in the process to FacePalm.

That was perhaps a bit too much to hope for.

MSNP was a neat little protocol. Messages were sent as mime messages. They did have a max message size, but the official client would ignore any headers it didn't know about and any mimetypes it wasn't expecting. This gave third-party clients a lot of ability to extend the protocol. For instance, I hacked in avatar support in Gaim (aka Pidgin) when I was maintaining that support.

MSNP8 is when all the terrible MSNSLP (MSN SLP-Like Protocol) stuff began, with the binary packets. Spent a couple months figuring out the content of those packets... And while avatars were part of the protocol at this point, custom content was no longer as viable. I can understand some of the reasons they wanted to change it, but in the end, I think they ruined a decent (if imperfect) protocol.

I've been a regular at a couple of different Starbucks locations over the past few years, and surprisingly, communities of people do develop over time. There are other regulars that you start to recognize, say hi to as you stand in line, and catch up with. I've met fascinating people by working at Starbucks. Engineers, managers, musicians, nurses, all friendly and equally happy to have someone else to talk to. Plus, there's the baristas, who I've also found pleasant to talk to.

Some days, though, you are alone at Starbucks, but it's a different kind of alone than working at home all day every day. You're surrounded by people, and when the alternative is zero social contact during your work day, it can make a difference.

They tried for many years to get us to change the name, but it never came down to any real legal battles of any sort. The name change occurred after I left the project, but I think it was a conscious choice on the project's end to finally change the name, give it a new identity. (Someone from Pidgin correct me if I'm wrong -- I was pretty out of the loop during that time period.)

If you can tie the shield into KBFS, that's even better. It's not enough to protect a company from attacks, though. People may still click that random document coming in via e-mail that claims to be from a co-worker. A mandatory technical solution on that end, no matter what the actual technology looks like under the hood, would be essential for protecting people from making these kinds of mistakes.

The value proposition of automatic and transparent public key cryptography is strong, and what I love about Keybase. Just thinking of other ways that can be applied transparently.

A team-based 1Password-type service would also be interesting, particularly one allowing heavy use of 2-factor authentication with something like a Yubikey.

Throwing my "I <3 Keybase" comment in the ring while doing some brainstorming here.

It seems to me that there's a lot of product opportunities in the corporate world that go beyond what Keybase is providing today. Chat and Git are interesting, but there's already a lot of momentum in both these areas. Been thinking how I use encryption and where things fall short today. One of those areas is build signing and hardware key management for our team.

Everything that goes on our servers get signed by an official PGP key. Only a couple people can sign builds, and each has a Yubikey with PGP subkeys on it. This is kind of annoying to manage. We use an airgapped computer that houses the private key, can create subkeys and assign to Yubikeys, can handle expiration management, etc. When we want to deal with this, we have to get the computer, unlock access, and deal with the command line. This is error-prone and annoying. Having a solution that allows for safe storage of a private key and easy management of subkeys on smartcards would be amazing without the need for an airgapped computer and a command line would be really interesting.

(The signing/verification part can probably be handled today by the keybase tool.)

Okay, that's maybe more specialized. Let's move away from paranoid server builds and go toward something similar that's gotten plenty of companies in trouble: Malicious e-mails. How often are we hearing about some poor employee receiving an e-mail that appears to come from a co-worker that contains a finance document with a trojan? Or maybe just a simple document with a form, instructions, and a link that results in information leaked to some third-party?

If there was a dead-simple way to sign and validate documents over Keybase (and I mean dead-simple, built for people who only know Word and Excel), for use in e-mail and document management, with marketing around "For $XX/user/month, you don't have to worry about getting hacked," I bet plenty of companies would bite.

I don't know what that looks like exactly, but just playing around loosely with some thoughts, it would be interesting (particularly for fully IT-managed systems) to have a Keybase Shield product that would automate much of the signing and verification of documents. It could tie into Word, Excel, etc. via their plugin interface and sign on save, and/or provide a big "Sign this document" widget on the side of the screen that a document can be dropped onto (or a Share action on phones). It'd then own the file associations for these documents, intercepting them when opening via e-mail or file servers, and would validate their signature. A document from the outside world (or one not going through the corporate-mandated signature process) would outright fail to open with an error message and instructions to ask the sender to please sign the document.

(Lots of details to work out there, but if this process could be made simple and mostly automatic, you'd help close a major attack vector that companies are susceptible to today.)

Anyway, it's great hearing your thoughts on how Keybase plans to make money. I've been in the same boat of loving Keybase but being uncertain about where it'll be 5 years from now. We'll keep an eye open for some paid products :)

AST-assisted diffing is something we've looked into for Review Board, and it's something we'll probably add at some point. There's certainly some benefit to doing it.

However, you don't need it for the case of "I've moved the class into a subclass which caused an indentation change." We handle that case by tracking indentation-only changes and by tracking moved code.

For instance, if you were to move a class or a method or some logic around within a file, we show that it was moved but not modified, saving you some review time. You can move an entire function into a class, with no modifications (or just a line changed here and there to reference `self` or `this`) and we intelligently show that. Saves a ton of time during code review.

If you nested a bunch of things inside a new conditional or subclass without otherwise changing the lines, we highlight just the indentation changes while making it clear the rest of the line is the same. Nest a 5 thousand line function inside of a new class, and you'll only have to worry about reviewing the class definition, not the indented 5 thousand lines.

You could get some benefits to this logic with AST-assisted diffs, to help you better know where a function/class/loop/etc. begins and ends (particularly with languages like Python), which can help you better represent some changes. You also get the benefit of knowing up-front about syntax errors. I've also given some thought to being able to "zoom out" of the line-by-line changes to a file and let you focus on the high-level structure of the classes/methods/docs of a file and how those have changed.

The downside to AST-assisted diffs is compatibility with language changes. It's important to have a sane fallback when the file isn't exactly as you expect it to be (such as if the language adds some new form of syntactic sugar but you're on an older version of the product doing the AST-assisted diffing, or you're parsing something that claims to be in a certain language but is using special syntax meant to be pre-processed during builds).

I'll try to give a bit of an overview to help answer the first three questions.

In Notion, all your documents are basically a big nested hierarchy of pages. Pages (generally) exist within another page, rather than simply being linked to (though you can link to pages in a different part of the hierarchy through either their URLs or by aliasing the page, letting a document live in more than one part of the tree at once). By nesting the pages, you get a nice table of contents in the sidebar.

Pages are composed of "blocks". These are just page elements, and most of these are the kinds of things you'd expect to see in a document (paragraphs, images, sections, bullet lists, etc.). There are some special ones, like TeX equations, inline discussion forums, and other things, but these are entirely optional.

Unlike a document in Word/Google Docs, blocks are more of a real entity that you'd interact with. For example, you can select a whole block (and any children) at once, drag-and-drop them elsewhere in the document (even to the left or right of other blocks, creating columns), link to them, and even transform them into other types of blocks (like bullet lists to numbered lists).

Pages themselves are actually a kind of block, which is neat. Let's say you have a giant page full of content, and you want to split out some of the sections in the page and put them in their own page. Simply click the block options for that section and choose "Turn Into -> Page", and now it's a new page linked where the section used to be, at the right place in the hierarchy.

Task Boards, Design Specs, etc. are really just templates. They're nothing special. You can make them by hand if you want to, or change them however you want. They're really just there to help you get going if you have use of them. No different than templates in Work, Excel, etc.

As far as WYSIWYG goes, since you're dealing with these page elements (bullet points, section headers, etc.), it really is pretty much WYSIWYG. You can select text or a header or whatever and change the styling a bit (colors, sizes, fonts, all to a limited degree).

Along with that, though, there's a form of Markdown processing. These are really more like keyboard shortcuts, though. Type "# " to get a section. Enclose something in backticks to make it appear as code. "* " for a bullet list. Things like that. It's not a full Markdown engine, though. There are a few bugs with some of these shortcuts, but they mostly work.

Editing in Notion is definitely a bit different, because you're kinda forced to think about blocks and hierarchy a bit more, but they've improved much of this over the past couple of months to make it more natural to work with. They've been hard at work with improvements, from the looks of it, so I'm expecting a lot of this to really improve more going forward.

Another happy customer here.

We started off with Hackpad and used that for years, and tried moving to Dropbox Paper when Hackpad was end-of-lifed. While a good product, it wasn't really good enough for what we needed. We were using Hackpad like a wiki, and Paper just wasn't (at the time, at least) built to really be effective for public content like that.

We moved to Notion, and while it's certainly more complex in what it can do, it's met our needs far better than Paper and even Hackpad have. Notion continues to improve pretty much constantly (I get excited when I get the blue banner at the top of the UI saying there are new updates), and the people we've interacted with there have been fantastic.

It's not perfect, but they've been hammering out the major bugs and shortcomings we hit when we first started, and recently pushed a big update that improved how free/paid teams work, added namespaces for pages, and a handful of other improvements here and there.

We have a lot of content in Notion now, and it's been pretty easy to keep that updated and to jump around. (The native Mac app has helped a lot with that as well.)

(Also not in any way affiliated. Just another happy customer.)

I'm pretty sure I've seen it at least 10 times now. I may have a problem.

That said, it helped me get through a (terrible) US Government class back in college. There's a surprising amount of useful information in that series.

I've heard this sentiment with 3D Touch and Siri before. I'm probably an outlier, but I use each about a dozen times or so a day.

3D Touch is one of the reasons I upgraded to the 6S. Lack of 3D Touch was the one thing that disappointed me the most about the new iPad Pro. I wasn't sure at first if it was something I'd end up using long-term, but it didn't take long for me to develop a lot of habits around it. Here are some of my daily actions through 3D Touch:

* When I go to Starbucks, I use 3D Touch to get to the app's Pay option. * I use it on the Phone app to quickly dial the people I call the most. * Same with iMessage. * I use it on Sleep Cycle to quickly start my morning alarm. * On Intercom to speed up launching/getting to the part of the UI I want (People vs. different support mailboxes). * Day One to quickly record a journal entry. * Drafts to jot down a quick bit of info (someone's name or something, or a thought) to later process/organize somewhere. * Pandora to quickly get to my most-used stations (I only really have a few I often use, so it's perfect)

When I need to place a call and am in the middle of something (getting ready in the morning, looking something up, making dinner, etc.), I use Siri. Actually, I'd say most of my calls are placed with Siri unless I have the phone in my hand.

"Hey Siri, call <person> on speakerphone" is pretty common here.

I also use Siri to start timers for laundry or to remind me of something I need to think about later. "Hey Siri, in 4 hours, remind me to do <blah>".

I hate naps, but sometimes I need them. "Hey Siri, wake me in 30 minutes."

I ask her every day in the morning what the weather's going to be like. Even though I live in Palo Alto and it's not exactly hard to guess. Super handy when I'm going to go somewhere else though.

I also use her as an app launcher pretty frequently. Mostly in the morning when I want to kick off some music at home. I'll wake up, start getting dressed, and say "Hey Siri, launch Harmony." Since that takes a few seconds to launch sometimes, I do that while I'm otherwise occupied. Then when I can get to the phone, I just have to tap the item on the screen to get music going.

My car will let me know when I have incoming texts, but I can't respond through it, so Siri's also my dictation if I'm stopped at a red and need to fire off a message to someone saying I'm late.

So that's how I use 3D Touch and Siri. Consider me a data point :)

I see these mentioned a lot, and sci-fi is big on the latter. The one I rarely see come up is "entertainment."

If we were traveling amongst the stars today, with our values and morality as they currently are, and happened upon a world of what we'd consider to be primitive life, we'd probably scoop some up and put them in a zoo, or broadcast them on TV. We'd want to study them, learn what makes them tick, maybe try to see if communication was possible, but in the end, we'd get entertainment value from them.

Even if we left them be and studied from a distance, the human race would be fascinated. New life! A new place! We like new things. The news would cover these creatures ("Are they a threat to humanity? News at 11."), they'd be woven into stories and shows and movies in one form or another. If we could safely bring them back, people would want to see them in person.

We'd get a lot of entertainment value out of these new creatures. We're a curious race who manages to get bored of spectacular things quickly, which is a large reason we continue to innovate and push forward.

There's no way to know for sure what would motive another intelligent race to advance to the point where they'd reach for the stars, but if any of them shared a degree of curiosity, I doubt they'd pass us up if they found us. We'd be something new for them.

Maybe we'd end up in their stories, their drawings, their videos, or even their zoos. Maybe they'd be interested in how we smell, or the way we dress and decorate ourselves, or the things that we watch on TV. Our languages, our fights, our culture. Or maybe just the way we go about our business, missing some big cosmological truth that's so obvious to them, as if we're adorable little children.

Maybe we'd provide just enough entertainment value to be worth a quick trip. Or a long stay.

Hey, thanks for the detailed feedback! It's always great to hear about use cases and what people need. Helps us shape things.

Something that's been core to our product's philosophy for a long time is to be extensible and to fit in with other tools. We're doing more to help there in 3.0, but we already have a very fleshed-out API and extension framework used to add on new features and capabilities, API, etc. The lack of an API for user account creation is clearly a pain point for you. I know I said we'd get that into 3.0, but I think I'm going to have to take that back.

I'm going to try to get it into the next 2.5.x instead.

> - Reviews need to be generated automatically when suitable trigger conditions are met. This means that there has to be a dedicated user account in RB that can create reviews on behalf of other users. Reviews also need to be automatically updated when new changes land in the branch under review.

You probably know this, but in case, or for anyone who doesn't, there's a permission that allows users to post or edit review requests on behalf of another user. I'll make sure that can be set in the API.

> Furthermore, I realise your permission model is tightly coupled with the underlying architecture, which itself builds on top of Django. Exposing the kind of functionality I ask for requires to expose and nest quite a few internal API layers. I do genuinely see why that has not been roadmap item so far. Codewise that is a big undertaking

Fortunately, large parts of this are already written for RBCommons.com (our Review Board SaaS) for our own use, and we should be able to port much of it over.

> Once you have native DVCS support and push-to-commit for fluid integration between other tools, RB has the ability become "just another tool". I see that as a good thing :)

It should be very cool :) Still a lot of work to get where we want to go, but it'll happen. Much of it already has, just not in a stable form yet.

> I haven't yet tried phabricator (evaluating it is on our infrastructure team's roadmap), but so far it looks like it tries to do too much.

I can't speak to their product. I believe we have different philosophies. Many tools choose to be like GitHub and do a little bit of everything under one product (which can be good if you aren't using other tools, or want to consolidate them all). We opt to focus solely on code review capabilities, trying to innovate in that area and plugging into other services/tools already being used. Pros and cons to both, but I certainly have my preference :)

Thanks again for the feedback! If you ever have more, or want to talk more about this outside Hacker News, definitely reach out! We have a dev-related list at https://groups.google.com/group/reviewboard-dev/, which I pay a lot of attention to, and others might have some good thoughts as well.

Oh I should be clear (misunderstood that extension). We're adding support for using Review Board as an OAuth2 provider, not to use another service for auth, so that services can better integrate into your server without having to share credentials.

Sounds cool :) I'd love to hear more about your setup if you'd be up to talk about it further (christian@beanbaginc.com).

Native support for OAuth2 is planned to land in 3.0 as well. We're focusing a lot on improvements for third-party integrations and enhanced extensibility with this release (along with some cool new review improvements).

Hi, Review Board founder here. Let me address these real quick.

1) This has come up before. We'll probably add it. Most places that ask for it really are wanting something like an auth backend that ties into another service, like LDAP/ActiveDirectory (which are supported natively), a Single Sign-On service (which we'll be adding support for in Power Pack, our add-on product), or something more custom. For those who do want to add via the API, it's something I imagine we'll do in the next major release or two. I'll make sure it gets on the roadmap.

2) Review Board 4.0 (which is in development, alongside the upcoming 3.0) features DVCS support that will make it a lot easier to update patchsets and to keep them together as a whole without having to squash commits or create a review request per commit or anything else like that. Reviewers can view each commit individually, or the whole thing squashed, or a range squashed, and we'll help visualize how the history of those commits evolve with each update (such as adding new commits to HEAD, squashing commits together, etc.). It'll be really nice when it's done.

We're also looking at adding push-to-commit through our in-development Git (and eventually Mercurial) wrapper service, rb-gateway, so that you can push a branch there and have it appear on Review Board, and keep updating that branch to update the review request.

And, we're prototyping support for pull requests (first for GitHub, and then for others later), so that one can submit a pull request and have it basically appear in Review Board. This is still in the very early stages, but it's a priority. May not be relevant to your workflow, but thought I'd mention it, because that's asked a lot.

Again, Review Board 4.0 is when a lot of this will make an appearance, but I'll try to get account creation via the API to happen in 3.0. (Just added it to our roadmap.)

My MacBook Pro is from 2012, but I have 16GB of RAM in it. I regularly have something like 10 windows with about 15 or so tabs in each. It can get bogged down at times, but generally works fine.

Chrome wants RAM, so I think that's the real blocker in your case.

Player wasn't crippled. It just served a different purpose. It was never meant to be on the same level as VirtualBox or anything, and existed to be a simple "run this VM" application.

VMware definitely mentally categorizes Horizon and such to be EUC, but Workstation and Fusion were as much EUC as anything else. It started as the division to own both View and Workstation/Fusion.

If you mean VMware Server, the GSX replacement, and not the ESX products, then oh boy do I have stories to tell :) I was one of the, hmm, 5 or 6 people who threw that together in a span of months. It was more of a mess than it appeared, under the hood :) We called it the Frankenstein Project.

But it worked, and it worked well. More a testament to the infrastructure we had built for Workstation, and our team's ability to work hard and work well together.

Hmm, I don't think management really ever forbid us from doing anything. I'll have to think about that, but that's not my recollection. It's more that we had a lot of customers in different segments wanting different things, and our own list of what we thought would make a good release, and only so much time and personnel to make things happen :)

A teammate just told us he's bummed he didn't have just a bit longer to work on Workstation, because he had a few things left he wanted to fix and rework for the next release. Our personal todo lists were so long, we could have filled another 10 releases... Shame we didn't have that opportunity.

Workstation was heavily developed up until, well, yesterday really.

I personally spent 2 years of my life, starting in 2008, bringing Unity to Workstation on Linux and making it work with every combination of Linux and Windows I could throw at it. That work was continued by a teammate for several years.

I spent 3 years rewriting most of the foundation, UI, and server infrastructure for Workstation 8, bringing the ability to connect to remote VMware ESXi/vSphere servers, along with the server component of Workstation 8. This work allowed VMs to be hosted on any server and accessed from any other server, and allowed VMs to be pushed between servers. 3 solid years on this feature alone, given just how much was needed to make that happen.

In the same release, we replaced the old Teams feature (a single feature that provided a multi-VM UI along with software-defined networking segments) with a series of more independent, more useful features. These were just a couple of the major features released in Workstation 8, and with all this came cleanup in the UI to keep the experience sane, not bloated.

That came out in 2011.

Workstation 9, released in 2012, came with a web-based UI for interacting with VMs called WSX (a feature I dedicated a bit over a year to). It also added UI refinement for the features that come out in Workstation 8, more remote VM support, hardware improvements (USB 3, Hyper-V, OpenGL for Linux VMs, nested/Inception-like VMs), locked down virtual machines for IT, and probably more that I can't remember.

Workstation 10 followed that a year later, and brought guest hardware support for tablets, enhancements for Windows 8 hosts, more remote VM improvements, better command line automation for remote-controlling/creating VMs, and a bunch of other things. UI-wise, it was a smaller release, but it did a lot for the hardware support.

I left around this time to focus on Review Board (https://www.reviewboard.org/) full-time.

Since then, they released 2 major versions: Workstation 11 and 12. From what I can tell, these were largely about hardware improvements and performance improvements, less about major UI changes, but there's a lot that has to happen for these improvements. Hardware improvements are crucial to keeping the VMs useful in many situations. Performance was also a focus. While building these releases, the team was also busy helping out the View team by helping them consume bits of the Workstation/Fusion codebase. They also begun development of AppCatalyst and Flex.

There's also work that happened on Player, Ace, and other things, all throughout.

So that's a lot of killer features in my opinion :) I barely scratched the surface of 8, and didn't go into all the stuff we did in 6 and 7.

We were all very proud of the product, and often spent our free time working on it. I should point out, this was not a large team by any means. It was an amazing team, though. A family. One that will survive these layoffs, one way or another.

I don't believe VirtualBox was a factor in this.

Thanks for the compliments!

Installation difficulty seems to very much depend on the environment. On many systems, it's trivial. A couple commands, and you're good to go. On others, it's far more difficult.

I'd love to hear where you've hit problems. One of my primary tasks at this moment is improving our installation story for the systems where it's more difficult, and knowing what problems people are hitting will help me in that work.

A lot of the problems we hit were due to having to support many versions of many distros, not so much a particular bug in one distro. That said, we filed bugs, provided patches, and even drafted XDG specs for some of the issues we were dealing with.

The problem is, even if we filed a bug report with a patch for a 3.0 release of some distro, and it was fixed in 3.1, we still had to support 3.0. That meant code that worked with both the buggy 3.0, and the fixed 3.1. That's not a big deal when isolated to one distro or one component, but we're talking all the major distros, various third-party libraries, etc.

We may have been a bit nuts, trying to keep such a wide variety of environments supported, but that said, we also got really good at it, and it meant we didn't have to force customers to make changes to their system that they didn't want to make. The products ran on distros so old that they still only shipped GTK 1.2 (though we eventually finally walled off some of the older ones when we started supporting only 64-bit processors).