Hacker Newsnew | past | comments | ask | show | jobs | submit | TheLastPass's commentslogin

> along with a notification to local or federal authorities

I think that might dissuade a lot of them, but one of the biggest problems I see with some of the red flag laws that have been implemented is the mental health professionals who have been involved are the only people who aren't allowed to report you to the cops. Anyone else can, with impunity, but not them.


Yes, I agree. It would have to come with the contention that there wouldn't be an arrest, punishment, etc, or that any confiscation would have a limited term. Perhaps someone, in their moment of clarity, would understand that confiscation is the best solution at the time. I think it's at least worth a trial run.

Also, I believe mental health professionals are allowed to report incidents where the patient has indicated they plan on committing a violent crime.


Until someone who has the authority to approve purchase orders but wasn't in the loop on this decides to use this vendor again.


A lot of companies have company-wide vendor blacklists.


It's a conversation with Amazon "Fulfillment Center" ambassadors, who defend Amazon and say they're very happy. But their Twitter accounts don't follow anyone, they're corporate-branded, they all recite near-identical messages, and they're being paid to represent what it's like working for Amazon, and they "happen to like working for Amazon". The way they speak sounds very scripted and forced, a la The Borg.


One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to.

When you're validating an idea, don't worry about making everything perfect. Worry about validating the idea. Once you're more confident that you're actually gonna do it long-term, then it starts being more beneficial to pay off the tech debt.


I think what you're saying is the more common use of "tech debt", basically just using it as a synonym for "bad code". Don't worry about code quality, figure it out later.

It ignores the stronger debt analogy -- sure, there is a high chance that the idea fails. But if it succeeds and, all else being equal, you have taken on a less tech debt to get there, you will be able to iterate on and grow it more efficiently. So to the extent you're taking on debt, it should be an explicit trade-off to increase your chances of proving out the idea. Which is not the same as "don't worry about bad code at all."

From what I've seen, when it comes to talking about tech debt from an early prototype, it's often an excuse/euphamism to be considerate to the people that wrote it. The truth is often that it's just bad code due to them being inexperienced or lacking the skill or discipline to write better code. Which I don't mean as an insult, it seems like there's a strong inverse correlation between the kind of person who's passionate enough about product over tech, and is creative/naive enough to build and validate a brand new product, and the kind of person who understands enough to architect a great system and make the best tech debt trade-offs.


I absolutely agree - that's the whole point of the article and my comment. If you're in an experimental space, and 9/10 of your ideas are never going to make it to market, I'd rather spend 1 units of time on each to figure out which one's going to work, and then 20 units of time redesigning it the right way (i.e. 21 units of time to be done), rather than 10 units of time on each to make them all ready for production (i.e. 100 units of time to be done). But those ratios will vary depending on how sure you are about what needs to be done next, so yes - you've gotta weigh the cost / benefit.


> One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to.

This happens with financial debt as well. It's the risk that drives interest rates. Financial debt is abandoned (or restructured) when people or companies file for bankruptcy, when homes are foreclosed on, etc. Sure, it might ding your personal credit history in some cases, but financial debt is constantly abandoned at little or no cost to the borrower.


I thought interest rates were more driven by inflation. Mortgages are insured, for instance, removing much of the risk, but you pay for that insurance much of the time (THAT'S driven by risk), but $500,000 is worth more now than it will be in 30 years, so you're gonna have to pay to get it fronted to you.


Maybe a better word than "technical debt" is "rusty Ferrari".

Would you accept a free rusty Ferrari tomorrow? If it would take $60k in repairs to get into usable form, and probably not that great even if you put in those repairs, which you have no inclination to do, probably not. Especially if you couldn't easily sell it. If you were a broke college student and it was in roadworthy condition, and you had no other way to make it to your job - probably you would.

This captures that it's not really that you're "$60k in the hole" if you accept the free rusty Ferrari. In a sense, yes, you are.

I propose rusty Ferrari as the new, more precise term for technical debt. "We have a lot of rusty Ferraris in our garage" isn't a debt, but I think might capture the meaning. "I don't want a rusty Ferrari in my garage" = I don't want this technical debt. Let's make it work with some rusty Ferraris = let's cobble together a hack we should probably throw away.

what do you guys think?


There is no difference. Regular debt is also discharged in bankruptcy.


But that affects your ability to borrow in future, whereas a canceled project doesn't affect your ability to write rushed code in future. Unless you get fired, I guess...


You’re nit-picking when I think the analogy is clear but it doesn’t effect your credit if the company you work for declares bankruptcy, so the comparison to the company’s tech debt seems to hold up even if you push it.


The whole thread is nit-picking. The point of bankruptcy isn't "fuck being fiscally conservative - we don't even know we want the stuff we're buying so who cares if we can pay our credit card bills", whereas that's literally how you should approach some projects.


Commercial lending has this component as well. Any real estate operator working at scale will have some experience with giving this or that project back to the bank.


Isn't that more of a similarity than a difference? When financial debt gets overwhelming you can declare bankruptcy and abandon the project as well.


No. Bankruptcy doesn't just eliminate the debt and let you move on consequence-free - it's a legal process in which a plan is put in place for everyone to get their fair share of what's left, or to recover from the debt without the debt itself destroying future productivity. It can also be very detrimental to your credit opportunities. If you abandon a project, you're just never going to repay the debt or suffer from any consequences of it.


delete the whole code (or just throw away the keys) and all the debt is paid.


Actually the general consensus in the US government would be that everything kills people and must be regulated by people who don't understand it and who have conflicts of interest. That way people will stop dying.


>> Hasn't Reddit been issuing shadow bans for the last decade?

vBulletin has been doing it for well over 15 years too.


If it's not a strong hash and the protocol doesn't include salting, it's not impossible. Rainbow tables exist. And they really only need to find a collision. Wi-Fi protocols, especially WEP, have had vulnerabilities similar to this before. Similar in the sense that if you sniffed enough traffic you could figure out the password (don't recall the specific mechanisms - but this could be one).


It's unfair to say that there is no salting. The PMK is derived from the WiFi network name (SSID) as well as the password [1]. The SSID acts as a salt here. Not perfect as SSIDs are often not unique, but it's certainly better than no salting at all.

[1]: https://www.ins1gn1a.com/understanding-wpa-psk-cracking/


So stupid they don’t use the MAC as the salt.


I said "IF" there's no salting. In any case, I'd be less concerned about SSID's not being unique as I am about the fact that the SSID of a specific target is trivial to obtain and almost never changed.


> I'd be less concerned about SSID's not being unique as I am about the fact that the SSID of a specific target is trivial to obtain and almost never changed.

Salts don't need to be secret, only unique. In fact, in this case the unauthenticated client needs to be able to compute the PMK from the password alone, so you can't keep it on the AP.


This is why we have rainbow tables.


Rainbow tables don't work here because the password is salted.


A salt can't do it's job when it's reused.

There are WPA rainbow tables for common ssid's available online.

If your ssid is "Linksys" it takes only moments to look up a weak password.


Unrelated to the point of the article, but since we're discussing lawyers and their knowledge of coding in a Silicon Valley audience: has anyone else noticed that many of the lawyers who specialize in software licensing actually have a very shallow understanding of common open-source licenses? I think I've worked with at least 3 firms now at my current employer, a medium-size (>2000 person) software company. When I've had meetings with them about compliance with open-source licenses, they seem to be unaware of really basic aspects of the licenses. I've had one that thought the ASL 2.0 left you wide-open to patent trolls because you gave up all of your patent rights. I've had another that thought we could simply stop redistributing GPL software and have no further obligation to provide a way to get our modifications to the source. Especially for someone who went to law school, it seems as thought most of the lawyers I've worked with haven't read the license text, but simply heard this and that about the licenses. Is this common among Silicon Valley lawyers, or have I just had bad lawyers? I'm sure there's a lot more to law in Silicon Valley than this, but this is even with the person they refer me to for open source license questions.


Not excusing shoddy lawyering but here are some thoughts:

1.Many of these lawyers probably don't actually specialise in open source. Especially if they work for companies as project or product lawyers. They've probably been allocated it as part of their remit, along with issues like contract and data privacy.

2. Open source is a niche within a niche (IP law). It requires a nuanced understanding of copyright and patent law but also requires strong understanding of software development practices. Concepts like GPL linking are really tricky to grok even if you are a knowledgeable IP lawyer.

3. Several popular open source licenses weren't written by lawyers and so can be a little ambiguous when read against the relevant jurisprudence. Most are not well tested in court and so it's hard to give definitive advice on how they work.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: