skysight-inc/HackerNews huggingface dataset:
I'm going to speak for OpenDoor here so someone from them can probably jump in, but the company I started and shut down was around financing house flippers and I have a background in both capital raising and real estate.

There are many types of 'house flipping' and most of the differences are just various shades of grey.

For illustration purposes:

At one extreme: Focus on buying dramatically undervalued assets, putting in minimum work and reselling. (Do this using lots of people labor in looking for deals.) - IMO, this is the only way to make money consistently flipping

At the other extreme: Buy houses, put dollars in to them and acheive an ROI (lots of people labor in rehab). This is what you see on "house flippers" or other TV based flipping shows. Typically these systems work when the market is appreciating, but the value the 'flipper' puts in is really questionable vs the market appreciation. Most of the people that do this strategy eventually end up getting hammered in a downturn.

Opendoor is basically disrupting the first group. They are using a quantitative process (automated valuation models), then overlaying a fundamental process on top (having someone look at the data to make sure it makes sense.) That is how they make sure they are buying undervalued assets.

The disruption happens because they are eliminating the huge amount of man hours it takes to find undervalued deals, by paying slightly more, and building a good brand and well as fine tuning their marketing channel.

At the end of the day, a certain percentage of people need to sell their house very, very quickly and OpenDoor will be able to pay more than flippers in the first extreme so they will gain a ridiculous amount of market share.

Downside risk: The risk is that they need to scale their operation so large to get economies of scale that when a downturn happens, they are too top heavy and end up getting financial destroyed. Many people may also assume that they could systematically missprice houses (pay too much), but I doubt that is a real risk.
If you're for instance relying on handlebars to escape displayed content from user input properly and your version has a vulnerability...
gen_random_uuid()

Exists in the pgcrypto extension.

Only does UUID 4, which should work for many applications.
Probably soon - they already added snoozing an email to Inbox

edit: if you want it now, we offer that functionality in gmail and inbox soon: www.streak.com
I was legitimately disappointed that I couldn't use this today (US/California). Is there any way I can signup for a notification when you expand to my area?

Congrats on the launch!
layering differences aside, there's a fairly important security difference here:

Because the proxy is examining requests, it can authorize them, and provide data to the back-end about what user was authenticated. A VPN usually just gets you onto the network, and doesn't provide much if any data to the service being accessed about what user and application is connecting.

A VPN is generally invisible to both sides of the communication, so you can tack on extra security, but it's harder to have the applications actually rely on it for authn/authz guarantees. In practice this means you have to log in twice: Once to the VPN, and again to the application. There's some ways to make that invisible to the user, though.
You are preaching to the choir on that second part.

It's actually why I like services like keybase so much, they are actually trying to tackle that problem (with their own set of issues, but at least trying).

I was more trying to point out that we can get to where we are now in the browser.

Solving the problem of key distribution and management is way outside the scope of what I was talking about, and it's far from solved by platform install tools.
I believe that was a necessary compromise to use Hangul on any software not authored by Koreans.

"These are characters from a country you've never been to. Each three-byte sequence (assuming UTF-8) corresponds to a square-shaped character." --> Easy for everyone to understand, and less chance of screwup (as long as the software supports any Unicode at all).

"These should be decomposed into sequences of two or three characters, each three bytes long, and then you need a special algorithm to combine them into a square block." --> This pretty much means the software must be developed with Korean users in mind (or someone must heroically go through every part of the code dealing with displaying text), otherwise we might as well assume that it's English-only.

Well, now the equation might be different, as more and more software are developed by global companies and there are more customers using scripts with complicated combining diacritics, but that wasn't the case when Hangul was added to Unicode.

For example: if NFD works properly, the first two characters below should look identical, and the third should show a "defective" character that looks like the first two except without the circle (ㅇ). It doesn't work in gvim (it fails to consider the second/third example as a single character), Chrome in Linux, or Firefox in Linux.

은 은 ᅟᅳᆫ

Of course, if it were the only method of encoding Korean, then the support would have been better, but it would've still required a lot of work by everyone.
Interviews absolutely should be grounded in trying to predict how a candidate would do on a job. That's the whole ballgame. The question is how to best do that. First, you need to run a repeatable process (my previews comment). Second, you need to look at the right skills. The approach we take is to track a lot, and figure out what works the best over time. What we've found to be most predictive (so far) is a base level of coding competency, plus max skill (how good an engineer is at what they are best at). So (beyond the coding portion) we don't actually care very much about what a candidate is bad at. We care about how good they are at what they are good at. To give as many candidates as possible the opportunity to show strength, we cover a number of areas. This includes back-end web development, distributed systems, debugging a large codebase, algorithms, and -- yes -- low-level systems (currency, memory, bit and bytes). We do not expect any one engineer to be strong in all of these areas (I'm weak on some of them). But they all are perfectly valid areas to show strength (and we work with companies that value each of the areas).

We've recently moved to a new interview processes organized around this idea of max skill. It's working great in terms of company matching and predictive ability. However, it seems we may have underestimated the cost to candidates of being asked about areas where they are weak. There's more negative feedback here than we've seen in previous HN discussions, and I think that the interview change may be behind that. I'm taking that to heart. I think we can probably articulate it better (that we measure in a bunch of areas and look for max strength). We're also running an experiment now where we ask engineers are the start of the interview which sections they think they'll do best on. I'm excited about this. If engineers can self-identify their strongest areas, we'll be able to make the process shorter and much more pleasant!

So, the bit shift question: that come up down one branch of a system design question that we used for a while (we've since moved to a more targeted version that is more repeatable). The (sub)issue involved adding a binary flag to a large data blob (this came up as part of a solution to a real-world caching problem). Adding a single bit flag to the front of a 1GB blob has a problem. To really add just one bit, you'd have to bitshift the entire 1GB. This is clearly not worth it to save 7 bits of storage (ignoring that that would not be saved in any case). You can just use a byte (or word), or add the flag at the end. When candidates suggested adding a bit flag at the front, we would follow up asking them how they'd do it (to unearth if they were using 'bit' as a shorthand for a reasonable solution, or if they really are a little weak in binary data manipulation). This was one small part of our interview. By itself it in no way determined the outcome of the interview, or even of the low-level systems section. Plenty of great engineers might get it wrong. But I don't think it was unfair.
100x this. I get a lot of energy and happiness walking in the sun in the morning. Something so simple, yet has a dramatic effect on my quality of life.
Easy fix. Number pad should come up with numbers in different random order each time.
It doesn't help when voter suppression efforts make access to voting rights prohibitive to people in cities, especially the poor. 4 hour lines to vote (because there are fewer polling places) are painful even when your livelihood isn't on the line.
Yes, smoke is bad. Cannot control the compounds that form in such an uncontrolled high energy environment.

Vaporizer on the other hand has clean inputs.
I had the same thing. Stayed at a really disgustingly dirty place. No toilet paper, no bed sheets, no curtains on the windows. Gave it a bad review and had the host rip me apart about it. "What the fuck did you expect? I would feed you grapes?".
> You are also out of luck if you ever used a trail with your account before.

No, if you've used a trial you won't get another trial, but that doesn't affect your eligibility for the free tier.
Show HN: I Am Making an 8-Bit CPU in Logisim
Hey HN,
I am making an 8-Bit CPU in Logisim and blogging about it.t's nothing fancy, really simple, unoptimized dumb CPU for sake of learning. I am no electrical engineer, I am just a self-taught dude who has programming as a hobby and wanted to dive deeper into abstractions.

So here it is, so far I wrote 2 parts:

[links redacted]

I welcome any and all critique and feedback, as I can be wrong about everything for sure.
Just give us access to high quality vape and oral versions instead. It has to be legal and properly supervised by FDA to achieve this. More than tobacco.
He does a couple of really good podcasts that're worth checking out.
Ironically, this cuts both ways. Existing folks who didn't care about this now care about it due to emoji. Yay. But this leads to a secondary effect where the idea that this is "just" an emoji issue is spread around, and people who would have cared about it if they knew it affected languages as well may decide to ignore it because it's "just" emoji. It pays to be clear in these situations. I'm happy that emoji exist so that programmers are finally getting bonked on the head for not doing unicode right. At the same time, I'm wary of the situation getting misinterpreted and just shifting into another local extremum of wrongness.

Another contributor to this is that programmers love to hate Unicode. It has its flaws, but in general folks attribute any trouble they have to "oh that's just unicode being broken" even though these are often fundamental issues with international text. This leads to folks ignoring things because it's "unicode's fault", even though it's not.
Set Up a Headless Raspberry Pi Hacking Platform Running Kali Linux
forget the mechanics thing, just do a snapchat channel you guys rock it on social media.
This example will only affect that particular user viewing the page, though. And once they hit refresh, that'll be gone.

If I'm following your other example with malicious input into a form; the snippet would have to pass server-side validation (likely, since it's probably checking for SQL injects). Then past that, when it gets rendered for other users, the view/templating would need to display the snippet as a script instead of just text, right?
rite you are ;)
Our Jenkins container analysis plugin now supports pipeline and policy mgmt
Considering the demographics of California, nobody really lives there, so that "war" would be short if such a thing were to occur.

If California does split it'll probably just employ a live-and-let-live policy with their wild eastern frontier. Leave the hillbillies alone and they'll leave you alone.
Sharing anything like this on a public forum is exceedingly unprofessional, regardless of whether the content is positive or negative. If candidates don't have an expectation of privacy, they won't provide honest answers, which drastically undermines Triplebyte's claims about more effective evaluation.

I took the original comment about the interview with a grain of salt(these things are inherently subjective). But it's fairly obvious now that they're as unprofessional as claimed. Hope no one from Apple or Facebook sees this.
I am done with Google! Except for Gmail, which I can't flee, everything else has been a disaster! A disappointment after a disappointment! Apparently, they focus way too much on hiring engineers with their notorious interview process and not on hiring people who can design and deliver sane and practical products! If they weren't a monopolist in search for too long, they'd be long gone!
I've also used it internally, works great.
I do feel like an outlier in that I really enjoy living in distinct seasons. It feel like it helps me mark the time internally, and reminds me that I'm a pretty small part of nature overall.
Compare for yourself.

https://smartasset.com/taxes/california-tax-calculator#IrgvH...

https://simpletax.ca/calculator

At wages of (All amounts are in USD):

$100,000 USD, $200,000 USD, and $400,000 USD, you will pay:

$32,000, $69,000, and $159,000 in taxes in California.
$28,000, $73,500, $169,000 in taxes in BC.

But that's just income tax. There's also Social Security/Unemployment Insurance contributions. In the US, 13%[1] of your salary up to $130,000 will go to social security contributions. In Canada, 10% of your salary, up to $40,000 USD will go towards the CPP and Unemployment Insurance.

So, at the $100,000 USD salary, you will pay $45,000 in taxes in California. In BC, you will pay $32,000 in taxes.

At $200,000 USD, you will pay $86,000 in taxes in California. In BC, you will pay... $77,500.

At pretty much every tax bracket, you will pay more taxes in California, and get less for them, then you would in BC. As it turns out, maintaining twelve super-aircraft carrier groups is expensive.

Mind you, BC is not all flowers and roses. The provincial government runs the place with all the integrity and forward-thinking of a banana republic.

[1] Yes, your employer pays half of it. That money would have otherwise gone towards your salary.
"Moot" point, not "mute" - https://en.m.wiktionary.org/wiki/moot_point
As far as I remember BeyondCorp required users to be equipped only with attested hardware (no BYOD). This device's health then was constantly being monitored and taken into account when granting / denying access. I'd like to see the differences between IAP and Google's internal BeyondCorp. Quick search did not reveal anything.
I noticed that GCE instances only offer 1GB of network egress, and then $0.12/GB thereafter, which seems rather steep. Is GCE only meant for use as a CPU engine/internal node of some kind? Is there a different product meant for edge servers that would handle external requests with outgoing traffic?
All you said is that the OS is different, not that it's more difficult...
The extremely poor JOIN functionality is what turned me away from Firebase a couple of years ago.

I come from 25+ years of SQL, and Firebase was my choice for essentially my first 'real world' NoSQL project. I was enjoying it right up to the bit where I had to extract data from 2, and 3 data tables at the same time in a single query. Couldn't believe how verbose and painful it was and it made me drop NoSQL for a while before more recently going back to it (with RethinkDB).
Not everyone thinks >75F is comfortable...imho, if you're sitting in the noon sun having a picnic, 65-70F is ideal.

Also, not everyone hates wearing a jacket everyday...
Most of the complexity in today's “real world” software is accidental (i.e., a consequence of past bad decisions), not demanded by the problem domain, so the argument that “we can't handle real-world software” doesn't convince me. I'd rather live in a world where every program in a high-level language is no longer than, say, 5KLOC, but those 5KLOC are perfectly well understood by their authors and anyone else interested.

As for the kinds of formal methods that you use: Mechanical verification no longer convinces me. It turns out that I don't just want to know whether a program is correct. I also want to know why it is correct, which parts of the program are closely related to which parts of the specification, how easily the program can be modified to satisfy a slightly different specification, etc., and these questions aren't easily answered by mechanical verification tools. (“Tweak the system's definition, re-run the tool” is for obvious reasons not satisfactory.)

Considering that human understanding of the very systems we create should be the ultimate goal, I'd say that we shouldn't consider a system “proven correct” unless the proof can be communicated to a human. This means the proof itself should be short enough. If the proof requires running program to exhaustively verify a long list of cases (e.g., as done in the proof of the Four Color Theorem), at the very least the program itself should be short enough.
Repost: https://news.ycombinator.com/item?id=10319428
If you don't specify a charity it goes into the general fund. It's mentioned somewhere in that page.
Sure, but all 3 of the projects listed had people very early on point out that back of the envelope calculations don't add up and warned them that their projects are going to fail. Each of those those groups proceeded to ignore or not understand the evidence presented to them and continued to collect money. At that point I consider it a scam. Ignorance is not an excuse.

That being said what we are seeing here is a education problem. The masses of people who (including government officials) who seem to be so gullible and lack basic science skills and critical thinking to understand how some of these technologies might work is astounding. And with the 3 efforts listed above it has slowly come out that the minds behind the idea did not know how it would all work either. A good example of that is fontus. This as dream big art design project. How awesome is that? We can make a 3d model of this cool device! A year later confessing to taking apart dehumidifiers to "understand" how they work as if it was some mistry. As if they could somehow crack this alien technology then they too could build one!

At the rate these too good to be true ideas are coming out one has to stop and think that maybe, just maybe, somebody is gaming the system.
If it's any solace, mechanical physics was one of my least favorite courses and I can't remember an instance where i've used it since.
> Running 30-person video conferences

Zoom provides 50-person.
That'll break for people who use "shapes" on the keypad.
Most engineers suck at technical interviews. Because interviewing is a separate skill that must be learned and practiced. So yes, you are an engineer, but you need to take some time and prepare for technical interviews before you go onsite. Search Google and quora you'll find lots of resources and stories.
Show HN: mdviewer – minimalistic GTK+ Markdown viewer/converter with Css support
Palantir will regularly buy its employees' equity fwiw.
> End-to-end encryption is very much counter to their goals.

What would those goals be?
Great feature, only a few years overdue...
How HMAC Signing Works
Studying the Internet Censorship in South Korea (2016)
DeepMind just published a mind blowing paper on general AI
Not really! Aurora would be available for PostreSQL soon!
I think you're being a bit hyperbolic - everyone seems to see snail mail / fax as quite different from electronic communication methods.

I've found most people tend to see email as the "slow/deliberate" electronic communication, and IM/Messages/SMS as the "fast/extemporaneous", so even conflating GMail doesn't really make sense (why do you think Wave failed?).
Same for us. We're migrating to GKE but are accessing Postgres over a gateway and leaving our DB heavy services on AWS... This was very good news.
If you grew up on the east coast, where you have about 1 week of pleasant weather in between hellish hotness in the summer and ball-shriveling cold in the winter, you'd appreciate SF's boringly middling weather.

I do miss the snow, but that's what Tahoe is for.
My impression is that those on the bottom of the recruiter rung do the really desperate stuff like hounding you with several weeks of emails every few days, calling you at your office, etc. If you're so unlucky to be a dead ringer for a position and have a rookie recruiter thinking they can wrangle you in, hold on to your seats.

I'd highly recommend folks read "Gurus, Hired Guns, and Warm Bodies: Itinerant Experts in a Knowledge Economy", great perspectives given from all three parties involved in this land of recruitment. Also covers some history that may no longer be well known why the state of affairs is as such.
Thank you!

Another quick question. Is there anyway to see during instance creation/usage if it is part of the free tier?

When I create a f1-micro instance, it shows the usual $5/month billing, but doesn't indicate any kind of 'free tier' usage. How can we know if any service we use will be a part of the free tier for sure? I guess I can wait a few days to see if any costs accrue, but I was wondering if there was a better way for everyone.
Yeah those are "benchmark" prices, which is a special MLS measurement designed to value a "typical" home. I decided to ignore that valuation method and instead use average prices because I'm not sure if a similar or comparable measurement tool as the benchmark exists for SF home valuations.

http://www.rew.ca/news/benchmark-vs-average-vs-median-what-s...
If only it worked on mobile.
The video they showed seems faked. Why do his other presses and swipes he makes after entering the password not show up in the thermal image? Why would they fake this?
At least at first glance, it looks like roff?

I use POD to write man pages, which is a widely supported, reasonably lightweight markup that generates nice looking man pages. (Example: https://raw.githubusercontent.com/libguestfs/nbdkit/master/d... )
Prime example is Cargill. $100B in revenues, privately held.

https://www.cargill.com/about/financial/credit-rating-inform...
The only BYOD device allowed is Chromebooks with a signed bootloader, aka no developer mode or Crouton.
Look, here's the thing. We all ought to be able to agree that you could build a digital computer out of pipes, valves, and diaphragms (the water analogues of wires, diodes, and capacitors). Does anyone believe that a sufficiently complex plumbing system would be self-aware? That a sufficiently complex plumbing network might become confused about whether it is, in fact, pipes and water?

Though, the other reason we're not living in a simulation is that reality is continuous, and numerical simulation can never overcome that barrier. But that point is more esoteric.