Updated!
HN user
dfcarney
Co-founder of https://tailscale.com/
In case this is helpful to anyone else, I opted out earlier today with an email to feedback@slack.com
Subject: Slack Global Model opt-out request.
Body:
<my workspace>.slack.com
Please opt the above Slack Workspace out of training of Slack Global Models.
Thanks! This is helpful. We need to make some changes to our pricing/plans and every bit of input will shape that.
(co-founder here)
To xena's point, we're not currently enforcing the limits :) We've been very cautious about that since, as I mentioned in a comment elsewhere, the limits have always been an experiment.
(co-founder here)
We're definitely considering it. We introduced the limits a while back as an experiment. In most cases, I believe the current limits don't make a lot of sense. Fundamentally, we were hoping to encourage the deployment of Tailscale to end devices (partially to increase users' security, partially to get a better idea of how widely Tailscale is actually being used). Unfortunately, the limits introduce the kinds of headaches that you're describing (and for IoT it can be a showstopper). The net effect across all users could be to actually discourage people from having fun and tinkering with Tailscale, which is the last thing we want.
Would you mind describing some of the other use cases you have for subnet routers? Do you have other mini k8s clusters you want to use them for? Other things? I'd love to learn more.
It’s a deep hole for a company to dig itself out of, not to mention changing the habits of people to explicitly document things elsewhere.
It would be neat if Slack reported stats on searches so that, for example, a company could better understand what key conversations should be moved into proper documents…but this is likely against Slack’s interests.
(Tailscale employee here)
I wouldn't say mistimed so much as "we were excited to get the post up". Node sharing is indeed in invite-only beta, though we're planning on opening that up very soon. Apologies for any frustration/confusion.
I was on the "silicon level debugging" team, which took test cases like this and boiled them down to x86, then through the CMS to p95 assembler, then down to the circuit and device level to figure out the speed paths. There were definitely some crazy issues we found. Honestly, I couldn't have done that job without relying on 80%+ of my undergrad courses (Computer Engineering @ Waterloo).
The issue I remember the most clearly was one that an engineer Simon Barrett discovered: a specific sequence of MMX instructions would cross-talk (and cause the occasional bit to flip) on two perpendicular busses in the pipeline when run at a specific voltage/frequency. It sounds simple enough, but imagine trying to figure that one out.
I worked at Transmeta for a short time (about a year) after my undergrad. I loved it. However, there was always a running joke that the stock ticker symbol should have been “HYPE”. It was sad to see things implode the way they did.
(Co-founder here). It's coming, I promise. I'm as excited as you are. We wanted to iron out the kinks on mobile (i.e. iOS) before duplicating them on another platform. Thankfully, we're past that point now.
(Co-founder here). If you're referring to the free tier, it only supports a single email address at the moment. What some people have been doing is to create a fake Gmail address and sharing that with their family/friends to use as a common login.
We've been exploring the idea for a free (or significantly discounted) "family" plan (or even something like that for small teams). Please stay tuned over the coming weeks for some updates to our pricing and tiers.
(Tailscale co-founder here). I certainly appreciate the feedback and suggestions. We've had pricing inquiries from individuals all the way to enterprise. Finding the right set of features at the right price is something we're going to spend a lot of time exploring (for instance, some larger companies don't care too much about ACLs, but some smaller ones really, really do). Right now, all I can say for certain is that our pricing page will change and that we're open to discussion.
I'd love to hear more of your thoughts on where you think we can add value and what it might be worth to you. If you're up for it, please email me at dfcarney@tailscale.com Regardless, thanks again for the input.
(Tailscale co-founder here). I also loved Crawshaw's post. It really took me back, though I certainly wasn't doing the kind of hacking he was.
I, for one, really appreciate the nod. I agree our motivations align and I look forward to hearing more about what you and team come up with. All the best on things at ZeroTier.
(Co-founder of Tailscale here) To that end, we started publishing a "blueprint" for people who want to DIY. There's more to explain (and questions encouraged). Please check it out: https://tailscale.com/blog/how-tailscale-works/
(Tailscale co-founder here.)
Building on what katnegermis said, this is what we're trying to help with. We integrate with identity management systems and handle the key management (and NAT traversal) on top of WireGuard, making it easier to deploy and manage.
If you're interested, a colleague of mine wrote up a blog post on how things work: https://tailscale.com/blog/how-tailscale-works/
That...and we haven’t made time to integrate a payment processor yet. Details, details...
(co-founder here)
Please email support@tailscale.com and we’ll help you out!
This is what we (https://tailscale.com) are working on! WireGuard is incredible, but adding some key management (that integrates with your IAM system) and NAT traversal really helps to round things out. I'd love to hear suggestions and feedback on what we're building.
(Co-founder here)
https://motion-project.github.io/ made it really easy for me to setup a webcam on my Raspberry Pi. Accessing that using HTTP over WireGuard (via Tailscale) from my iPhone when out of the house was one of those "delight and amaze" moments.
(Co-founder here)
We integrate with existing identity providers (for instance, GSuite, Okta, Ping, AD) to perform authentication and generate keypairs. Public keys are shared via a coordination server (and each device's private keys never leave it). There's an (optional) additional layer of authorization required in which an admin reviews the endpoints asking to connect. A combination of user and machine certificates makes it possible to ensure that both the users and machines are managed properly.
So, basically, we're enabling the "enforcement" side of identity and policy management at the networking layer, with visibility into users and their devices.
I hope this helps! Please keep the questions coming.
Check out Arithmetic Coding: https://en.m.wikipedia.org/wiki/Arithmetic_coding
I work at a company where a “take home” assignment is a routine part of evaluating candidates who have made it through the initial screenings and face-to-face discussions. However, we set up all such assignments as small contracts (say 2 - 10 hours, depending on the candidates availability, the position, etc). We pay market rates and try to be as accommodating as possible; sometimes, a candidate just can’t fit it in, so we find alternatives or take more of a risk when we offer them a job. In general, however, it’s a great system for us and, I feel, very fair. I see it as a cost of recruiting and risk mitigation.
A friend of mine wrote this article. If anyone has suggestions on how to get ahold of more data (or ideas on further analysis) then, please, speak up.
First and foremost, if you have an idea for a good product then just work on that. Don't complicate your life with consulting unless there's a dire need to save up a bunch of cash. It'll be easier to work on that while maintaining a 9-to-5 job, as opposed to trying to build a product while running a consulting business.
That said, consulting is a great way to learn a lot, gain experience, make good money, and figure out what you don't want to be doing. If you want to go this route, read on...
Speaking from experience (having incorporated two software consulting firms and worked at that for a few years), I completely agree with the comments about sales/selling be such an important part of things. If you don't enjoy this (or have someone on your team who does), then you're going to get worn out pretty quickly. However, if you can land 1-2 big clients and setup some kind of continuous (ex. retainer-based) relationship then you're golden.
One option is to try and contract from your current employer. You obviously have the experience and the relationships already in place. Your employer won't be happy about you leaving, but might be amenable to hiring you on a short-term gig.
An alternative is to subcontract. Expect your rates to be lower, but you'll have more opportunity to gain valuable experience and won't bear the risk/burden of landing clients yourself. It's a lot easier to find your own contracts once you have a few projects (and a network of contacts) under your belt.
Regardless of your approach, advice I always give to people when they ask me about starting a business are: get a good lawyer ; and get a good accountant. Don't take the cheapest options because you'll regret it later. Find people in the space who come recommended, whom you like, and who have a track-record in dealing in your line of work.
Whether or not you decide to incorporate is up to you (talk to the aforementioned lawyer), but in my experience it's a no-brainer.
In terms of legal, you'll also want your lawyer to provide you with a standard NDA and contract that you can use in all of your engagements. Any lawyer with experience should be able to provide this pretty cheaply (at a fixed rate, hopefully).
In terms of an accountant (or a small accounting firm), you won't need much to get started, but a 1-2 hour consultation to get your bookkeeping and invoicing setup will save you a lot of time (and grief) later. Make sure that you can hand easily hand your invoices, bank statements, receipts, etc. to your accountant when it comes time to file your taxes. Again, if you cheap-out on this it's going to cause you a lot of pain down the road.
Other notes from experience:
- Switching from consulting to product is difficult and almost always fails unless you're willing to make a clean break. As a consultant you eat what you kill; as soon as you stop working then your revenue stream drops to zero. I've seen people try to work around this by expanding their consulting firm to handle larger and larger projects, but then the people at the top just spend more time managing everything and have even less time to work on products.
- You'll eventually come up with a good product idea, at which point you should be willing (and able) to completely stop consulting to work on it. This transition will hurt, but you should have enough cash saved up to make a go of it.
- It's okay (in Canada, at least) to start working as a sole proprietor on some (smaller) contracts, but don't expect any client to be amenable to you changing the nature of your relationship with them half way through a contract (for instance, if you decide to incorporate).
- The larger the client/contract, the more likely you'll need insurance (errors & omissions, liability, etc). This doesn't come cheap. I recommend starting with smaller clients and projects to mitigate this.
- Figure out what taxes (if any) you need to charge ahead of time and be very upfront about this (and your rates).
- If someone wants you to be on-call (ex. 2-hour response time to a phone call), then great. Charge them more for it.
- If someone wants you on retainer (ex. 20 hours/month for dev ops), wonderful. Consider giving them a discount for multi-month agreements because it's a low-risk and guaranteed revenue stream.
- Make it very easy for clients to pay you. Include all of your payment information on each invoice. Have multiple payment options, if possible.
- Expect to terminate agreements with some clients. This sucks, but it's sometimes necessary.
- In your contract, be sure to state that the client doesn't own the work product (copyright, etc) until they pay you. This doesn't mean you don't deliver things according to schedule if payment is a little behind schedule, but you have some recourse if things ever get nasty.
- Finally, be sure to check your current employment agreement to make sure there's nothing that would get you (or your colleague) in trouble if you both decide to leave and start a company. Two things come to mind: there might be some onerous (and probably unenforceable) non-solicitation clause that a lawyer could twist to state that you solicited your colleague (or vice versa) to leave (this probably won't be an issue); and there might be some non-compete that you have to be careful about if you're consulting on similar products/features to your current employer. In both cases, I think this would be low-risk, but talk to your lawyer.
At least nobody can say the NSA isn't creative.
Cited post from December: https://news.ycombinator.com/item?id=6900625
"Real-time" is a bit of a misnomer as far as databases are concerned, especially if you're talking about a system that defaults to eventual consistency. I think they would have been better off saying "high-availability".
Google, for one, has been doing this kind of thing for years. Dremel (http://research.google.com/pubs/pub36632.html), for instance, was the subject of a paper they published after they'd been developing and using it internally for years. It's never been open sourced, but there's now Apache Drill (http://incubator.apache.org/drill/) which is based on the same paper. In short, it's part marketing, part recruiting, and part ego. I'm hopeful that Twitter will at least publish a research paper that digs into some of the nuances of Manhattan and compares/contrasts against other technologies.
Also, hi Mat!
How about, "Pick your battles"? I agree that it's ideal to own something vital to your business or a product, but if you're trying to validate an idea and get something to market ASAP then outsourcing and/or using 3rd-party services can make a big difference. Trying to do everything yourself is a slippery slope. Related: http://en.wikipedia.org/wiki/Not_invented_here