justinludwig

It sounds pretty fair to me. I would look at it more like I'm getting a stipend to spend a few months learning if I really want to devote the next 5 years of my life building stuff with this guy. But if you're looking at it more like it's just a paycheck, then it's not going to be a good fit.

"Get shit done" is by far the most important attribute of your first few employees. You need people who can work independently without a lot of direction, and focus on the right things while the rest of the world burns around them.

They don't need fancy credentials or to be super smart or have a great internet presence; what you should look for is a track-record of shipping, and evidence of independent work; and when you interview them, find out if they have good judgement, if they have a sense of when to trade off perfect for good enough, if they're able to diagnose and fix things when they're broken.

As you grow, you can add more traditional engineers to build a more conventional, well-rounded team. But most companies don't get to 20 employees if their first 5-10 aren't able to work quickly & make good decisions without getting side-tracked on all the myriad little distractions of designing the perfect framework for the framework, office politics, dev environment isn't quite right, etc, etc.

> - System design at ~whiteboard still feels reasonable / CS basics.

Bingo. Timeless classic for good reason.

Code review also can be good, not in a "can you spot the 17 bugs" way, but rather as a tool for discussing what makes code good, what make a code-review good, what are the tradeoffs in this particular section of code, what tests or other safety checks might you want to add to this particular code, etc.

More about what you actually do -- I'd suggest something like "Secure, Sustainable Open Source: We partner with open source projects to monitor their upstream dependencies for security fixes, and automatically rebuild and distribute our partners' projects with those fixes. Our partners don't have to change what they do, and we share 70% of our subscription revenue with them."

Also:

> New SecureBuilds are created whenever upstream CVEs are available, with a 6-day SLA for critical vulnerabilities.

Surely this should be "New SecureBuilds are created whenever upstream fixes for CVEs are available" -- you cut new builds for the fixes, not the bugs, no?

Simply being first isn't the moat -- _switching cost_ is the moat. You've got to get people using your app in order for being first to matter. And the easier it is for those users to switch, the smaller the moat is.

IE6's moat wasn't that it was first at anything, it was that it was installed as the default browser on all new Windows machines -- switching was work. And once lots of custom web applications were built that used IE6-only features (or required IE6-only bugs), switching became impossible.

You realistically only have time for one of the following:

1. be a serious student

2. be a serious athlete

3. be a serious maker

4. be a serious business-person

My advice would be not to take any of them too seriously -- enjoy college, enjoy your sport, enjoy tinkering, make connections. Don't worry about starting a company until after college. Take advantage of your college years to learn, work on other people's projects, try out new things, and invite others to collaborate with you.

If you're brimming with ideas now, you'll have just as many in four (or six or eight) years, and you'll have gained invaluable connections and the know-how to execute on them. (But if before then a great opportunity falls into your lap to start a business with some of your fellow students or professors, don't be afraid to take a sabbatical from being a student and athlete and having a life, and dive into it for six months or a year.)

This tactic is usually used as a diversion, either to bury an important email message (like a notification that your credentials to an important account have changed) in a flood of garbage messages, or to keep you focused on your email instead of keeping tabs on your usual responsibilities (like say to monitor the entrance to your office suite).

If this is her personal phone number, then it's likely available from any number of "legitimate" data brokers; plus likely would be part of various database dumps you can buy on the dark web. It's pretty easy for someone who knows what they're doing to spend a few minutes of research on social media to find several employees of a small company, lookup their personal contact info, and message them claiming to be the company's CEO.

To protect your employees, let them know that either a) you'll never call or text their personal phone number; or b) if you call or text, it will always be from a known good phone number (which they can put in their phone's contacts).

I loved Lemmings (the game) as a kid! But as an adult, I found out everything I thought I knew about lemmings (the animal) was a lie: https://www.snopes.com/fact-check/white-wilderness-lemming-s...

This was part of the original Netscape 6 pre-releases in the late 90s. Looks like the search button was added to the URL bar for milestone 11:

http://www.andrewturnbull.net/mozilla/history.html

Buy a cheap Android phone on eBay, use it on Wi-Fi for work accounts instead of your personal phone.

OWASP Cheat Sheet Series [1] is a great place to start (for websites or HTTP services generally). Also see their Web Security Testing Guide [2] for a comprehensive list of security issues to watch out for:

[1] https://cheatsheetseries.owasp.org/index.html

[2] https://owasp.org/www-project-web-security-testing-guide/lat...

Set up an Asterisk box and connect it to a SIP trunking service (like Twilio or a bunch of other similar providers) to make and receive regular phone calls. Use the same provider to separately send and receive text messages (via the provider's web API). With a little elbow grease, you can replicate all the features of Google Voice using that (plus have a lot more possibilities for customization and automation).

The downside is that while you can get a basic set-up done over a weekend, it will probably take you much longer to actually get everything set up to your liking (and you'll probably need to do a lot of background reading and research just to figure out what you want to set up, how it all fits together, etc).

Yes. You can use a combination of the built-in passkey support on some of your devices (like the platform authenticators built into iOS, macOS, Windows, and Android), external hardware security keys (like YubiKey, Nitrokey, OnlyKey, etc), and/or third-party software-based authenticators (such as 1password).

Passkeys are not like passwords, where you typically register a single username+password combination for each account you use. Passkeys are more like SSH keys, where you typically register multiple SSH keys for each account you use, one for each device from which you want to access the account.

If you only use a single device or platform, it's possible to register just a single passkey for each online account you use. Even so, most technical-savvy folks will want to register at least two passkeys for each of their important accounts (to at minimum have at least one backup authenticator in case they loose access to the primary authenticator). And for accounts that you regularly access from different devices, if you find it convenient to use the built-in platform authenticator on each of those devices, you would register a separate passkey for the same account on each device.

The FAQ section of this page might help clear up some of the questions you have about passkeys:

https://fidoalliance.org/passkeys/#faq

Or you can use an external hardware security key; the latest versions of most security keys (like YubiKey 5, Nitrokey 3, etc) support Passkeys. Passkeys are basically just U2F 2.0, allowing you to use an asymmetric key pair as the first factor instead of the second.

Yes, that's the CVE referenced by the Phoronix article and the oss-security post. The researchers coordinated their disclosure with the security teams from the major Linux distros, so packages with the fix should be available for most of them today.

"Makes money" in the sense that someone will pay some money for it, absolutely. "Makes money" in the sense that it will adequately compensate you (and your collaborators), almost certainly not.

Most successful businesses take years to build (at which point they suddenly look like an overnight success to outside observers). But you can definitely prove out the concept for a product (or several) in six months -- and decide then if it's worth continuing to pursue, or if it's time to go back to a paying job.

Comments from a similar article posted yesterday: https://news.ycombinator.com/item?id=37023806

The tech industry as a whole is really diverse -- what you see in the news or promoted on Twitter, Facebook, etc is just a small part of it. Some parts of the industry are male-dominated, but there are lots of sectors and companies that aren't -- particularly if you step outside of Big Tech.

Here are a couple lists of female founders:

* https://femalefoundersfund.com/portfolio/

* https://www.fearless.fund/portfolio

And a couple lists of prominent female programmers:

* https://blog.codersrank.io/12-female-developers-you-should-f...

* https://www.fullstackacademy.com/blog/female-identifying-cod...

Comments aren't outdated. Obvious code doesn't need to be commented, and code should be written to be obvious where possible.

But where it's not possible to write obvious code, it should have comments explaining _why_ the code is doing what it's doing. Usually this will include references to external sources like issue trackers and software-design documents, or at least to other parts of the code.

Also, really hairy bits of code (like multi-page functions etc) often need comments just to explain what the heck it does (but in that case, it should also include an explanation of _why_ it's so hairy, and the ramifications to making changes to it).

_The Mythical Man-Month_ is still worth a read, although many of its insights that were super hot takes 50 years ago have been pretty much adopted into the mainstream.

Normal people can use Apple- or Google-provided cross-device Passkeys synchronization. You don't have to manage your own Passkeys if you don't have the wherewithal to do so.

Passkeys are a win for the tech-savvy because of phishing protection; and they're a win for non-tech-savvy people (and everyone who provides tech-support for them) because they don't have to worry about managing their own passwords anymore.

Passkeys are better than really strong passwords: Passkeys' killer feature is that they are phishing-resistant. Phishing isn't just for "stupid people" -- even people who are quite careful with their security hygiene are susceptible to being phished in the right situation.

I empathize with your anxiety about losing a physical security device. I feel the same anxiety about losing access to my password manager. What helps me manage my anxiety is having a solid backup framework. The same applies to physical security devices -- having additional backup passkey devices help make me feel more comfortable that I'm not going to lock myself out of anything important.

Sure, but in America, anybody can sue anybody for anything. Your lawyers are of course right that having a clause in a software license disclaiming all liability for its use could be helpful in your defense -- but it's not an ironclad guarantee that you will not be sued or even found liable for your contributions in the event that it causes some kind of catastrophe. If this is a major concern for you, you should probably avoid contributing to FOSS altogether.

However, if you don't own the software and don't distribute the software and don't have any other kind of relationship with the users of the software, it's likely going to require the plaintiff to demonstrate particularly egregious conduct on your part in order for a court to find that you have some liability for damages arising from the use of the software. But YMMV.

The _tune_ we now commonly use for "Hark the Herald Angels Sing" was composed by Felix Mendelssohn in the 1840s (for the Gutenberg Cantata that this blog post talks about) -- but the _lyrics_ were originally written in the 1730s by noted English Methodist Charles Wesley (who wrote many, many Christian hymns). The Wikipedia article on this song has a more accurate synopsis of its history:

https://en.wikipedia.org/wiki/Hark!_The_Herald_Angels_Sing

Ouch, that's a painful mistake! But good on them for coming clean about it, and explaining fully without a lot of corporate doublespeak.

I think you're overthinking it. Nftables may look more complicated at first, but once you start using it, you'll find it's much easier to maintain firewall rulesets with nftables than iptables.

If you want to learn it, go through the exercise of building out a ruleset by hand. Take the iptables ruleset of some server with which you're familiar (or use the Arch wiki's example iptables firewall [1] if you don't have a good example at hand), and convert it line-by-line to nftables. Look up in the nftables docs for an equivalent of each iptables line (you're looking in all the right places for documentation -- nftables own wiki has lots of good information, as does the Arch and Gentoo wikis).

When you install nftables, many distros will include a small starter config file at `/etc/nftables.conf` or /etc/sysconfig/nftables.conf`. Add rules to that file, and run `sudo nft -f /etc/nftables.conf` (or `sudo nft -f /etc/sysconfig/nftables.conf`) after each change to replace your old ruleset with your updated version. The `nft` command will check your syntax before applying the new ruleset, and if there's an error, it will instead abort and show you an error message that points to the problem line.

Then use `sudo nft list ruleset` to view your current ruleset -- you'll notice some cases where nftables has re-written your rules to use the canonical form of the rule (or substituted a constant for a standard value etc).

You can use the `iptables-translate` tool if you get stuck, but it won't really help you learn anything -- just as running some tool that generates a bunch of Rust code won't help you learn Rust. If you want to learn Rust, you have to write Rust code -- and if you want to learn nftables, you have to write nftables rulesets.

[1] https://wiki.archlinux.org/title/Simple_stateful_firewall

Is this what you're looking for?:

https://www.procustodibus.com/blog/2022/06/multi-hop-wiregua...

I do (with the NoScript browser extension: https://noscript.net/). The main reason is to reduce my attack surface. A secondary benefit is it eliminates most ads and other annoying distractions.

I think it's mostly wishful thinking -- the supposed mother, L25 Ocean Sun [1], is the oldest by far of the Southern Residents, and the only one living who could be Toki's mother. Most females don't make it past their 50s, and most males don't make it past their 30s.

[1] https://killerwhales.fandom.com/wiki/L25_Ocean_Sun

Maybe it's just bad luck, bad interviewers, etc -- but are you applying for jobs that would make best use of your skill set?

Given your past experience, you sound like you'd be a good fit at a smaller company (or perhaps a small, independent team at a larger company) -- places where as an IC you're needed to make important decisions, solve problems, and coordinate directly with lots of different stakeholders, independently and without much management. You probably wouldn't be as good a fit at a large company, or a place where you're needed to just shut up and write beautiful code.

With your history, if I was considering you for a dev job, I would be mostly interested in learning more about your leadership, mentorship, program-management, product-ownership, problem-solving, communication etc skills -- if those were particularly strong, I would be excited about how I could use those skills on my development team; and I wouldn't be so much worried about your programming skills (or your ability to explain Big O etc) as long as you could show that you could solve a basic fizzbuzz problem or two.

But if you haven't been doing much coding in recent years, you should probably also sit down and spend some time working through a bunch interview-style programming questions. If you're out of practice, putting in some reps will help you get back into the groove of thinking through problems programmatically and banging out code. If you do that for an hour or two every night for a couple of weeks, that should get you back into shape (and build your confidence) so you can do at least a passable job on the coding parts of job interviews.