Hacker Newsnew | past | comments | ask | show | jobs | submit | nop_slide's favoriteslogin

No it won't. Americans are too deluded by car culture to ever let that happen.

You will see highways with 55 lanes each way, but you won't see an operational high speed train in the US. There are simply too many people opposed to any kind of real progress in this direction, and even the proponents of HSR or mass public transit have no shortage of excuses.

Furthermore, HSR also requires some level of last mile connectivity by local mass public transit. There is none of that in places like Texas, and again the public imagination has not moved on from some kind of 1950s car culture utopia, thats about "freedom".

In reality, cars are parked 90% of the time, and driven by tired, frustrated drivers in bumper to bumper traffic for the rest of the time.

The reality is that 20% of Texans (also other cities/states) spend $1000 or more a month on car. In many areas in the US, cars are the number 2, sometimes number 1 expense.

Here is a mass transit map of Berlin vs Houston: https://i.imgur.com/HwBGUcU.jpg

There is no HSR happening. Americans have dug a hole so deep with car culture and other Nimby delusions such as "what will happen to my home values", that there is no coming back from this.


This site ripped its entire database from Flashpoint Archive (https://flashpointarchive.org/), including all of the metadata, screenshots and "Hall of Fame" list. As a contributor to Flashpoint, I'm not opposed to sites like this (as long as they remain nonprofit endeavors), but I think they should make these facts clear.

In addition to its desktop client, Flashpoint Archive also offers its own experimental web frontend called 9o3o (https://ooooooooo.ooo/static/browse/), also using Ruffle for playback. It's not as fleshed out as Flash Museum yet, but games are embedded at their intended resolution and other efforts have been made to improve game compatibility, so I think it is already a worthy alternative. Check it out!


Are you kidding? Narcolepsy epidemic caused by swine flu vaccine in UK and Northern Europe in 2009/2010.

https://www.narcolepsy.org.uk/resources/pandemrix-narcolepsy

In fact, there are many, many vaccine-related long-term injuries that are well-studied and were totally not detected until well after the fact.

In fact, there's an entire medical school textbook about it, if you want to really know, published by Wiley, called Vacines and Autommunity: https://www.amazon.com/Vaccines-Autoimmunity-Yehuda-Shoenfel...

The corporate press does everything possible to make it seem to the common person that vaccines are the very single medical technology that has zero side-effects and zero long-term safety issues, but that couldn't be further from the truth.

(Wiley is not some crazy conspiracy theory crap, they make legitimate textbooks for colleges everywhere.)

Not to mention, the question itself is biased. You should really ask, Is there any example of an entirely new medical technology (really, three, if you consider the LNP) which post-deployment caused long-term safety issues?

And that would be a resounding yes.

And, please again note, even knowing all I do about all those things and the dangers of vaccines, I still am more vaccinated than you, having taken, e.g., rabies vaccine, even knowing the not-insignificant risks involved.

However, there was a risk I'd catch and be injured by rabies.

There's almost zero risk I'll be injured by covid, lol.

I mean, as well, look at the injuries being caused by the vaccines: They happen to people like me, young and healthy. Covid only hurts the fat people my age. Why would I take the side of the risk that hurts people like me?


Three tools that I think are less widely known compared to how useful they are: jq, progress, and pv.

`pv` (pipe view) is rather simple but I use it for viewing a lot and sometimes rate-limiting transfers. Usage is simple: `curl huge-file | pv | some-operation` will show you the progress (okay, curl already does... but pv works for any pipe input, and pv can work in line mode with -l so you can see how many lines (records, presumably) it processed).

`progress` is even simpler! Just type progress in a random terminal while, in another, you are running an operation like cp, gzip, etc.

    $ progress
    [10123] bzip2 /tmp/test
            32.5% (127.0 MiB / 390.6 MiB)
Use -m to monitor instead of doing a one-shot. This will also allow it to calculate the remaining time (for anything running at more than a few kilobytes per second).

I also love progress just because it's such a hack. It hooks into the process and monitors file operations. Simple but effective. Somehow it works super well because it manages to ignore everything irrelevant and only shows you the file handle you care about (you can give it hints if necessary, I've used that maybe once in ten years).

`jq` takes JSON data and either pretty-prints (default) or operates on it:

    $ echo '{"whoami": "root"}' | jq
    {
      "whoami": "root"
    }
    # imagine colored output above

    $ echo '{"whoami": "root"}' | jq .whoami
    "root"

    $ echo '{"users": [{"name": "abc", ...}, ...]}' | jq '.users[].name'
    # prints the name of all users in this array

    $ curl localhost/api/v1/users | jq '.users[] | "\(.name) \(.age)"' | sort -n -k 2 | tail -1 && echo "is our oldest user!"

Classic "confused deputy" problem. What is the current recommendation in the modern microservices world to solve it?

When user agent (UA) makes authenticated call to service A, which in turn makes call to service B:

UA -[user auth]-> A -[????]-> B

how to pass authentication information from A, when making a call to B? Options I can think of:

- pass UA token as is. This has a problem that token becomes too powerful and can be made to call any service.

- pass own token and pass user auth info as an additional field. This doesn't solve confused deputy problem, since own token can be used with any user auth and service B can be tricked to make request for data in B not belonging to user

- Mint new unique token derived from tuple (A own token, UA token, B service name). B then extracts user information from the token presented by A and authorizes request. This seems to solve confused deputy problem, because A has no access to other UA tokens, so it can't mint a new token for a wrong user. Downside is that token minting should probably be done in another service and it requires making a call to it for almost every request between two microservices, making it a bottleneck pretty quickly.

I've never seen last one in real life, maybe it has some critical flaws I am failing to see?


The best explanation of blockchain has to be (unsurprisingly) 3Blue1Brown: https://www.youtube.com/watch?v=bBC-nXj3Ng4

Would highly recommend watching this video for anyone who hasn't already.


How did you get into contract ethereum development? What does that require in terms of skill set (C/C++)? Where are you finding these jobs that claim high demand? I'm thinking about breaking into contract development and working on block chain tech, and this seems like a good opportunity.

I have intimate personal experience with the FCRA. Sadly I don't have an hour to talk about it at the moment, but ping me any time. Short version: it's one of the most absurdly customer-friendly pieces of legislation in the US, assuming you know how to work it. There exist Internet communities where they basically do nothing but assist each other with using the FCRA to get legitimate debts removed from their credit report, which, when combined with the Fair Debt Collection Practices Act, means you can essentially unilaterally absolve yourself of many debts if the party currently owning it is not on the ball for compliance.

The brief version, with the exact search queries you'll want bracketed: you send a [debt validation letter] under the FCRA to the CRAs. This starts a 30 day clock, during which time they have to get to the reporter and receive evidence from the reporter that you actually own the debt. If that clock expires, the CRAs must remove that tradeline from your report and never reinstate it. Roughly simultaneously with that letter, you send the collection agency a [FDCPA dispute letter], and allege specifically that you have "No recollection of the particulars of the debt" (this stops short of saying "It isn't mine"), request documentation of it, and -- this is the magic part -- remind them that the FDCPA means they have to stop collection activities until they've produced docs for you. Collection activities include responding to inquiries from the CRAs. If the CRA comes back to you with a "We validated the debt with the reporter." prior to you hearing from the reporter directly, you've got documentary evidence of a per-se violation of the FDCPA, which you can use to get the debt discharged and statutory damages (if you sue) or just threaten to do that in return for the reporter agreeing to tell the CRA to delete the tradeline.

No response from the CRA? You watch your mail box like a hawk for the next 30 days. Odds are, you'll get nothing back from the reporter in that timeframe, because most debt collection agencies are poorly organized and can't find the original documentation for the debt in their files quickly enough. Many simply won't have original documentation -- they just have a CSV file from the original lender listing people and amounts.

If you get nothing back from the reporter in 30 days, game over, you win. The CRA is now legally required to delete the tradeline and never put it back. Sometimes you have to send a few pieces of mail to get this to stick. You will probably follow-up on this with a second letter to the reporter, asserting the FDCPA right to not receive any communication from them which is inconvenient, and you'll tell them that all communication is inconvenient. (This letter is sometimes referred to as a [FOAD letter], for eff-off-and-die.) The reporter's only possible choices at that point are to abandon collection attempts entirely or sue you. If they sue you prior to sending validation, that was a very bad move, because that is a per-se FDCPA violation and means your debt will be voided. (That assumes you owe it in the first place. Lots of the people doing these mechanics actually did owe the debt at one point, but are betting that it can't be conveniently demonstrated that they owe the debt.)

If the reporter sends a letter: "Uh, we have you in a CSV file." you wait patiently until day 31 then say "You've failed to produce documentary evidence of this debt under the FDCPA. Accordingly, you're barred from attempting to collect on it. If you dispute that this is how the FDCPA works, meet me in any court of competent jurisdiction because I have the certified mail return receipt from the letter I sent you and every judge in the United States can count to 30." and then you file that with the CRA alleging "This debt on my credit report is invalid." The CRA will get in touch with the debt collection company, have their attempt timeout, and nuke the trade line. You now still technically speaking owe money but you owe it to someone who can't collect on the debt, (licitly [+]) sell it, or report it against your credit.

I just outlined the semi-abusive use of those two laws, but the perfectly legitimate use (for resolving situations like mine, where my credit report was alleging that I owed $X00,000 in debts dating to before I was born) is structurally similar. My dropbox still has 30 PDFs for letters I sent to the 3 CRAs, several banks, and a few debt collection companies disputing the information on my report and taking polite professional notice that there was an easy way out of this predicament for them but that if they weren't willing to play ball on that I was well aware of the mechanics of the hard way.

[+] Owing more to disorganization and incompetence than malice, many debt collection companies will in fact sell debts which they're not longer legally entitled to. This happened to me twice. I sent out two "intent to sue" letters and they fixed the problem within a week.

[Edit: I last did this in 2006 and my recollection on some of the steps I took was faulty, so I've corrected them above and made it a little more flow-charty.]


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

Search: