Am I the only "founder" / "entrepreneur" that doesn't really appreciate these special labels? They're generally something I only hear from the VC tech startup crowd, and usually in the context of breathless veneration.
I'm running a business. I'm not special, a new breed of business man, and I don't need a special startup-glorifying vocabulary for what I do. I'm just another person running a small business -- something people have always done, and it's something that parents (and everyone else) understands.
A neighbor recently started a coffee shop. She puts in long hours, manages the books, orders food, directed the installation of the sound system and kitchen, manages the kitchen staff, makes and serves coffee, and works the cash register.
Nobody is calling her a "founder". She's just a small business owner. She had to raise capital, her business could expand into a large chain, she could (but isn't likely to) become the next Starbucks, or even get bought out by Starbucks. She could also fail miserably. Is it really all that different from what we do?
I can kind of see the cost point - though most would argue that the lifetime earnings of someone with a college degree far outweigh a $100K investment.
Do those studies on lifetime earnings really isolate for other factors?
If dropping out of the college track isn't considered a valid, supported choice, then the only people that drop out will be those that have fallen out of the system. Is it a surprise that the majority of those students then fail?
But the time thing kind of bugs me. As driven as HN is this may be a minority position but I really don't believe you should be working (in a 9-5 career style job) between 18-24. I really don't care so much abou t college, but have fun, go out, date guys and girls, travel, there are so many things you should be doing at that age then starting a business and you'll end up better for it.
I got the "having fun" and dating out of the way between 16-18 (I dropped out of high school and moved out at 16). Everyone needs time to figure things out and grow up, and there shouldn't be a rush to start a business, but avoiding significant responsibility until you're 24 is unnecessary, carries a heavy opportunity cost, and is a waste of some of your most productive and formative years.
I didn't start my career until my late 20s and I don't regret that at all.
It's great that this worked out for you, but I have to say -- starting work in my field at 16 meant I had 10 years of experience when I was 26, and that expansive lead time on my contemporaries has been invaluable and allowed me to bring a breadth and depth of knowledge to my work that most people simply don't have, has ensured that I remain well ahead of the curve, and has provided me with a considerable backstop of experience to draw on when running my own business.
Given that I still love my life's work -- and that I have a few good working decades still ahead of me -- if I were given the choice, I wouldn't trade in those initial years for any other opportunity.
The problem here is that good UX isn't borne of qualitative analysis -- you have to build something worth analyzing to begin with.
Once you do start analyzing, what do you do with the results? You can try to make small tweaks -- it can be worthwhile if what you have is already good. If what you have is bad however, no amount of rigorous analysis is going to solve the artistic problem of coming up with a cohesive vision of something better.
The way I describe this to people is: "Usability science can only test a hypothesis. It doesn't give you a hypothesis to test."
Not to mention the problem of hill-climbing… you may think your test results are amazing, but you can't tell if you're really at a peak or in a valley with a lot of mist obscuring a potentially even higher peak..
we don't apologize for working hard. we're a startup trying to make it in a competitive business.
Past a certain amount of time, you're spinning your wheels, doing bad work you'll have to clean up later, and pushing yourself towards an early burn-out.
It's unhealthy, non-sustainable, a bad cultural precedent.
If there's no other choice, then do it -- we all have. But don't be too proud of it; it's not something you want engrained in your culture.
jeeze man, it's 60 hours a week (assuming that we never leave early or take a day off).
It's nowhere near the hours worked by a first year analyst at an ibank, or by a first year associate at a law firm.
Bill is not saying we are particularly proud of how much we work, just that we aren't apologizing for it. Especially when we are talking about the first 5 employees in the company.
Trust me, I don't want to be working 12 hour days a year from now, but it's what the company requires right now. I enjoy coming to work every day and working on something I love. I'd much rather do that for 12 hours a day, than watch the clock for 8.
I don't see any economic forces that would trigger a burst. In fact, I see most entry-level jobs demanding more education now than ever before.
A college degree, if required, has always been a -soft- requirement for most professional jobs. It is sometimes used as a first-pass filter, but it's unlikely that the reviewer will make it down to your "Education" section if the "Skills" and "Experience" sections are sufficiently impressive.
People aren't getting jobs because they didn't get enough education, not because they got too much.
No, people aren't getting professional jobs because they don't have any experience or novel qualifications that set them apart from their competition.
The majority of recent graduates just spent 4 years in college instead of gaining relevant experience, so, yes. The economy is tough, they don't stack up to the competition, and adding more schooling wouldn't improve matters.
Their competition probably spent the last 4 years working.
In general, BSD assembler tends to be pretty stack heavy for cultural/engineering reasons. I don't think it ultimately matters all that much if you're fiddling around on your personal machine.
It's depressing that your post hasn't received more attention. Your control systems should be on a private control network, not exposed to the wide internet.
OpenVPN is capable of providing a much, much smaller attack surface than OpenSSH (see http://news.ycombinator.com/item?id=1665773), and can be run entirely chroot'd and setuid such that even if an attacker does compromise OpenVPN, they can not necessarily gain further access.
There seems to be a prevailing lack of understanding that bad passwords are not the only concern when using SSH. The daemon itself may be vulnerable to exploit (and in the past, it has been).
Using a non-standard port for ssh eliminates the need for this altogether. This is almost a no-brainer, and it's the first thing I do when standing up a server.
No, it doesn't. Running a port scan and finding your "hidden" SSH port takes very little time.
Placing your SSH port behind a hosts.allow restriction ensures that you've reduced your attack surface to only the hosts (or networks) you've permitted.
Better still, set up OpenVPN, use its HMAC[1] support to stop unknown users early, and don't expose any other daemons to the internet.
The rationale for this feature is as follows. TLS requires a multi-packet exchange before it is able to authenticate a peer. During this time before authentication, OpenVPN is allocating resources (memory and CPU) to this potential peer. The potential peer is also exposing many parts of OpenVPN and the OpenSSL library to the packets it is sending. Most successful network attacks today seek to either exploit bugs in programs (such as buffer overflow attacks) or force a program to consume so many resources that it becomes unusable. Of course the first line of defense is always to produce clean, well-audited code. OpenVPN has been written with buffer overflow attack prevention as a top priority. But as history has shown, many of the most widely used network applications have, from time to time, fallen to buffer overflow attacks.
So as a second line of defense, OpenVPN offers this special layer of authentication on top of the TLS control channel so that every packet on the control channel is authenticated by an HMAC signature and a unique ID for replay protection. This signature will also help protect against DoS (Denial of Service) attacks. An important rule of thumb in reducing vulnerability to DoS attacks is to minimize the amount of resources a potential, but as yet unauthenticated, client is able to consume.
--tls-auth does this by signing every TLS control channel packet with an HMAC signature, including packets which are sent before the TLS level has had a chance to authenticate the peer. The result is that packets without the correct signature can be dropped immediately upon reception, before they have a chance to consume additional system resources such as by initiating a TLS handshake.
I don't find using hosts.allow terribly useful as the people that tend to want to ssh into servers that I control are often mobile, with IP addresses that change regularly.
The point I'm making, though, is that every instance of someone running a dictionary attack against one of my servers was a script kiddie running a tool against a range of IP addresses. Changing the port ssh runs on to something high eliminates this entirely.
The point I'm making, though, is that every instance of someone running a dictionary attack against one of my servers was a script kiddie running a tool against a range of IP addresses. Changing the port ssh runs on to something high eliminates this entirely.
Those are the attacks you see. The script kiddie with a 0-day would be much less obvious.
There are straight-forward ways to architect your infrastructure such that you solve the dictionary attack problem AND the 0-day problem, none of which require the hand-waving security (and user annoyance) of moving SSH to a non-standard port.
The security provided by a non-standard port is laughable -- it's like putting a child-proof lock on your front door.
If you're worried about dictionary attacks, turn off password authentication. If you're worried about 0-day vulnerabilities in SSH, leverage defense-in-depth (require well-secured VPN connectivity before allowing SSH access). If you're worried about user's machines being compromised and their keys stolen, leverage two-factor auth.
I'm running a business. I'm not special, a new breed of business man, and I don't need a special startup-glorifying vocabulary for what I do. I'm just another person running a small business -- something people have always done, and it's something that parents (and everyone else) understands.
A neighbor recently started a coffee shop. She puts in long hours, manages the books, orders food, directed the installation of the sound system and kitchen, manages the kitchen staff, makes and serves coffee, and works the cash register.
Nobody is calling her a "founder". She's just a small business owner. She had to raise capital, her business could expand into a large chain, she could (but isn't likely to) become the next Starbucks, or even get bought out by Starbucks. She could also fail miserably. Is it really all that different from what we do?