skysight-inc/HackerNews huggingface dataset:
Ram Dass once recalled the first time Hollingshead gave Leary LSD. Leary, Ram Dass (who was then still Richard Alpert), Ralph Metzner, and others from their group were staying at Millbrook and continuing their research with psylocybin that they'd started at Harvard when Hollingshead turned up and offered Leary LSD. Leary at first turned his nose up at LSD, but eventually tried it.

Then, Alpert reported, Leary did not speak for days. Everyone in the group was scared, and Alpert told everyone to stay away from the LSD while they waited for Leary to come back to them. After five days Leary finally spoke and the first word out of his mouth was "Wow". Then they all tried it.

I can't find it now, but I also remember hearing an episode of the Psychedelic Salon[1] podcast where Lorenzo Hagerty talks about how he came across an old letter of Myron Stolaroff's where the latter warned another psychedelic luminary about Hollingshead, calling him a consummate liar and saying that he shouldn't be trusted.

Incidentally, Stolaroff was deeply hurt by being conned by yet another psychedelic luminary, Al Hubbard, another legendary and mysterious Johnny Appleseed of LSD.

Psychedelics certainly do seem to attract tricksters (perhaps because they also attract naive idealists, who are irresistibly ripe pickings for the tricksters). Hollingshead, Leary, and Hubbard were all tricksters, as was Sasha Shulgin, who was very fond of practical jokes.

There was an interesting "psychedelic reunion" between Leary, Hubbard, Humphrey Osmond (who coined the term "psychedelic"), Sidney Cohen and others at Oscar Janiger's home in 1979.[2]

I found the video of this reunion fascinating because it seemed that all these larger than life psychedelic pioneers, who'd probably all done psychedelics hundreds if not thousands of times seemed quite ordinary, uncomfortable, unenlightened, and even gruff and sour to one another.

For instance, Leary seemed to desperately need to be the center of attention and Hubbard seemed extraordinarily uncomfortable and taciturn while Leary needled him. Later I learned that Hubbard absolutely detested Leary. That explained it, and provided evidence (if any more was needed) that psychedelics didn't inevitably turn people in to saints or enlightened beings who love everyone and who's feathers couldn't be ruffled by anything.

A couple other interesting recordings were the "Lone Pine Stories" with Myron Stolaroff [3], where he talks about being given LSD for the first time by Hubbard, and a Q&A session[4] by Stolaroff and Gary Fisher, who'd treated schizophrenic children with LSD.[5]

[1] - https://psychedelicsalon.com/category/people/myron-stolaroff...

[2] - https://www.youtube.com/watch?v=U-sfDEEcMQ8

[3] - https://www.youtube.com/watch?v=mMZ-oopMBog&list=PLCB4ED9E98...

[4] - https://www.youtube.com/watch?v=qMUO0dP77rI

[5] - http://www.maps.org/news-letters/v07n3/07318fis.html
Then it must be "big old brown cardboard fridge box".
>TL;DR: VOTE! Make your voice heard!

What if none of the candidate represent your voice?
Yes, along with binary trees, but there are cache-friendly alternatives like unrolled linked lists and B-trees.
I'm not really sure it has something to do with having children. I would say it's much simpler: either you care, or you don't, whatever is your current age. I'm pretty sure those 'senior' architects we already that reckless back in their twenties.
This is not politics, it is a technical matter. Being correct is important not being loud or bold! The authors argument is infuriantingly wrong and dangerous even. If you disagree show me which part of the post describes any specific risk, any specific threat or a comparison showing the marvelous benefits of not encrypting email? I mean until this post I didn't think anyone hated email more than myself, but emotions should not triumph logic. I have seen first hand unencrypted email being used against users. The tone of the writing distracted from a calm technical discussion. A missed opportunity!
I've seen Jason Gregory talk about per frame arenas in Game Engine Architecture as a fundamental piece of how the Naughty Dog engines tend to work.

Totally agreed that they aren't required for shipping great console games (and they're really hard to use effectively in C++ since you're pretty much guaranteed to have hanging references if you don't have ascetic levels of discipline). This is mainly just meant as a "here's an example of how they can be used and are by at least one shop".
Job Positions At Relayr – Industrial IoT Powerhouse
If you're only trying to solve the very narrow problem of entering a PIN to authenticate to the system, then sure. When you said "during keyboard input", I thought you were being more general, but I suppose you must have meant during keyboard input of the system PIN.

I don't think that PIN is the only sensitive information that matters, though. Android supports a numeric keypad input mode for apps. If I'm entering my credit card number into some app (Lyft, Amazon Shopping, etc.), that seems pretty sensitive. Maybe more sensitive than the system PIN even, because if I know your system PIN, I can't necessarily do anything with it unless I have physical access to your device or you've re-used the same PIN elsewhere.
I wonder what if we decide that 'fate sharing' is OK, i.e the client request flow (not the entire process) fails when a network step fails. How long can a system stay operational after it started before the whole thing grinds to a halt? Seconds? Hours? Days? Would there be a huge ding or small ding on the SLIs?
Using homomorphic encryption (HE) as an underlying technology for trustworthy elections is IMO a much better application of HE versus using HE for ML/AI applications, where performance requirements are incomparably higher. While there seems to be some limited progress on the HE acceleration front, potential improvements are limited by datasets size and algorithm complexity issues. I would argue that, for secure ML/AI applications, using technologies based on microprocessor-level secure instruction codes (e.g., Intel Software Guard Extensions aka SGX enclaves) is a much better option.
I do wonder about the wisdom of this up or out (to some level usually) some times. For example, you can’t be SDE I at Amazon for 10 years. But why not? If I’m doing a good job as a SDE I, I’m happy with the job and pay and just want to keep doing it what’s the problem?
Yes, I had the option of becoming professionally accredited if I I'd the 4 year instead of the 3 year programm, but its relevance is kinda limited
In that case, I hope somebody points me at a few of them. My guess is that if we look at the circumstances, they won't hold a lot of lessons for us.

As an example, the IRS is still running 60-year-old code: https://www.nextgov.com/it-modernization/2018/04/irs-60-year...

Is that because that code and hardware is especially good? Because the initial design and research process was so perfect that people are still entirely happy with it? I'm guessing not.
What you describe makes me think that you pivoted from an engineering role into a product role in order to make agile to work for you. This only reaffirms what I said, because if agile really empowered you as an engineer that transition would not have happened.
Jack, while incredibly powerful has been a huge hurdle for pro audio on Linux. I'm looking forward to Pipewire being the default audio interface. Hopefully it drives a revival of the Linux sound engineering community and new software projects. Specifically the lack of a user friendly loop/sample-based recording tool like Ableton Live is glaring.
I don’t think there’s a single discussion about boot camps that doesn’t discuss the immense cost of having to take months away from your money-earning life.

Why do you feel that this is an under appreciated topic?
“Shareholders having at least $20 million in value of A or B shares and an inclination to sell shares to Berkshire may wish to have their broker contact Berkshire’s Mark Millard at 402-346-1400. We request that you phone Mark between 8:00-8:30 a.m. or 3:00-3:30 p.m. Central Time, calling only if you are ready to sell.”

$BRK.B holder myself — What is this? Is this essentially if you have a big enough position you can sell us your shares directly for a better price than on the open market? Doesn’t that seem unfair to retail/small investors who have to trade on the open market?
How does it compare to TimescaleDB [1] ?

[1] https://www.timescale.com
observing marriages and watching movies about marriages probably tells you as much about marriage as watching movies about computers and watching people type on computers will tell you about programming.
Would you rather live in a world dominated by USA or USSR or China or Nazi Germany?

Remember you don't get to take away everyone's missiles.
BJ's models are breathtakingly simple and universally applicable. Highly recommended reading
Even I have half a mind about releasing something that I cannot commit to for a little bit - the initial bugfix stage, at least. I would say a giant like Uber hurts themselves more in terms of PR when not being conservative enough about putting source out there. People inevitably gravitate towards big player "open sauce" as it implies some commitment.

A company should first put their own system through hell and decide that "yeah, this is good, we are sticking with this", before luring people to use it.
I remember when Runescape added that to opening your bank account. Perhaps it was to deter bots, but also to stop any key/mouse loggers from giving away your secrets.
> The way Uber brands them suggests that they're suitable for use in production environments, but so far that hasn't been the case with anything they open sourced outside a narrow envelope that resembles their own operating model.

Not a contradiction. Many of these tools are suitable for use in production, almost by definition, since they are being used in production, at Uber. They might or might not work in your environment out of the box. But they are certainly often likely a better starting point than an empty editor, even when they do not. Most of the ones I am familiar with, are happy to get PRs generalizing them to more varied environments.

> they're nothing more than interesting repos amongst a sea of interesting repos.

As someone who has open-sourced on GitHub: research prototypes hacked together for a research paper deadline in grad school, class projects, for-fun hacks, and also production tooling I built as a paid engineer, I'd say there is a big difference! :) And there would still be a big difference even if the later were somehow never touched again after the first "we are open-sourcing this!" commit.

That said, we do try to maintain the things we open-source. Standards of support vary because individuals maintaining these projects, and their situations, vary. This is true for non-OSS internal tools too. In my experience, having gone through the Uber OSS process twice, and having started it a third time and decided against releasing (yet?), Uber does try to make reasonably sure that it's open-sourcing stuff that will be useful and is planned to be maintained. At the same time, they have to balance it with making it easy to open-source tools, otherwise too many useful things would remain internal only.

Also, note, some of these tools have exactly one developer internally as the maintainer, and not even as their full time job. For example, I am the sole internal maintainer[1] for https://github.com/uber/NullAway and also have 3-4 other projects internally on my plate, most of which are in earlier stages and need more frequent attention[2]. If and when said developer leaves, effort is made to find a new owner. This is not always successful, particularly if the tool has become non-critical internally. Sometimes, leaving owners retain admin rights on the repos and keep working on the tool (Manu, NullAway's original author, co-maintains it), but I don't think anyone is suggesting that that should be an obligation.

Finally, obviously, nothing here is the official Uber position on anything, just my own personal observations. This doesn't represent my employer, and so on. I am also pretty sure most of this is not even Uber specific :)

[1] Not the only internal contributor! Also, there is one external maintainer, as mentioned a few sentences later. But in terms of this being anyone's actual responsibility...

[2] Just to clarify, I think between Manu's interest, my own, and it being relatively critical tooling at Uber, NullAway is pretty well maintained. But I can understand why that isn't always a given for all projects.
Many of the points made in the article seem pertinent to me, however I think thinking in terms of discrete levels of seniority is counterproductive. I also think that there isn't a single dimension of seniority that we should talk about.

To give a precise example, in my previous job we had very hierarchically senior people who understood the industry and the business side very well and of course knew the company's platform very well. Oh the other hand, strictly in terms of technical competence I think they lacked a lot of the basic mental framework. Their code was atrocious (core code in classes of 1000+ lines with no documentation or tests, lots of copy-paste), their choice of technology and methodology parochial and antiquated (think Java 5-6, Ibatis in 2016 + a lot of in-house built stuff, no code reviews, no QA etc.).

This kind of people in some ways would rank as competent architects and in some other ways as fitting the good old adage "20 years of experience - the same year repeated 20 times".
I’ve always understood an arena to use a bump pointer for allocation and to support only a global deallocation, as the GP describes.

A pool or slab allocator separates allocations into one of a range of fixed-size chunks to avoid fragmentation. Such allocators do support object-by-object deallocation.
Can’t wait to follow this. I’ve been going through the official book these past couple weeks. As someone who’s never used systems languages (mainly a js / node person) I was able to write a redis-like database quickly on top of TCP. I’ve also picked up async / await and how it works in rust.

There’s so much to learn but the compiler is surprisingly helpful. I loved Typescript and it is like TS on steroids. When I get stuff compiling I have so much confidence.
US Postal Service: 4 Ways Blockchain Can Be Used Throughout the Supply Chain
> I’ve seen ex-engineers in management positions...forget how important it is to offset technical debt

I see this across industries. It seems easy for former insiders to lose the ability to empathize with those in their former positions.

Another example: teachers who become principals.
There is barely any attention paid in this article to things like the fact that if you are in certain demographic segments you are very likely to be juggling several part-time jobs that schedule at the last minute, and have to deal with getting to the polls on a day that is not a mandatory holiday. Or with the way these demographics tend to be underserved by polling locations, and targeted by “vote fraud prevention” measures deliberately designed to disenfranchise them. There are a couple sentences that vaguely glance in this direction when it discusses that there can be a lot of bureaucracy around registering.

Also not mentioned: prisoners and ex-cons are largely denied the right to vote. Florida lifting that on ex-cons should be interesting.
Double is an order of magnitude.
Berkshire Hathaway was responsible for 1.5% of US corporate taxes in 2019
I think SQLite could store and retrieve an extremely large amount of data as TEXT even before adding recursive CTEs, and you could do LIKE '%FOO' || BAR || 'BAZ%' queries to retrieve substring data from them; nevertheless, as far as I know, you couldn't encode Turing-complete queries in a SQL query before recursive CTEs.

Conditional looping is not strictly necessary if you're willing to accept an infinite loop with a "halted" flag set as halting. Moreover, conditional looping and unbounded storage is not strictly sufficient; the loop needs to be able to depend on an unbounded part of the unbounded storage, for example, although not necessarily within a single iteration (which is impossible in many Turing-complete models of computation). So, for example, a finite automaton that stores matched parts of its input string on an output printout, but cannot consult that printout, does not thereby achieve Turing-completeness. Moreover, nondeterministic pushdown automata with ε-productions have conditional looping and unbounded storage that they can actually consult during computation, but they are not Turing-complete; they can only recognize context-free languages.

I don't think you can reduce Turing-completeness to a laundry list of language features in that way, because you can always construct an automaton that restricts the ways those features can be combined so as to avoid Turing-completeness.

This is not, as it may seem, merely a perverse form of computational masochism; on the contrary, it is often considered highly undesirable for a program to unexpectedly enter an infinite loop or perform an arbitrary computation for an attacker, and this is in constant tension with our desire to make our systems simultaneously more powerful, more general and flexible, and less complicated. So work like Meredith Patterson's Language-Theoretic Security and Turner's Total Functional Programming represents important advances in the kinds of systems we can practically build.
I really had a lot of hope for bootcamps in general and ISAs in specific. I thought the alignment of incentives might make for radically more effective education.

I was very wrong. The ISA incentive appears to be nothing to the VC/startup incentive to Show! Massive! Growth! as you chase ever-larger chunks of money. Somehow we've gone from "move fast and break things" (which is not a terrible slogan to encourage experimentation on non-consequential things) to "move fast and break people" (which horrifies me).
She opens the thread by stating that she is a black woman from the Bronx. Then there's nothing in the thread that says she's been treated differently for being black, for being a woman, or for being from the Bronx.
OK, so the Blumberg campaign arguably erred by being so open about this effort. Unless, as others note, it was just consciousness raising. Or getting Twitter blamed, or whatever.

But what's interesting is what this portends for the coming campaign. Will Twitter, Facebook and Instagram be suspending all accounts that post ~duplicative political content? And if their policies vary by candidate, will that be firm evidence of bias?

This is going to make 2016 look like 2012, I suspect.
TSDBs are a special case of databases. And oh boy, time-series is hard.

Your regular RDBMS is going to be either write-heavy or read-heavy. You can pretty easily[ß] optimise the database for one of these utilisation patterns. But a TSDB basically combines the worst of both worlds: telemetry at any scale is important, and monitoring reliability in an always-online system is not optional.

TSDBs are written to very frequently; even at a reasonably low scale we could be talking about couple of hundred thousand writes every few seconds. But because they are also used for system-wide monitoring, they are read from all the time.

ß: a read-heavy regular DB has the ratio of reads:writes in thousands, perhaps millions; a write-heavy DB can be read from a couple of times every few seconds, but can be written to at a rate of tens of thousands of entries per second. You - or your expensive DBA - can optimise the DB for one of these patterns, but not for both. TSDBs have to support both patterns at the same time, so their internals have been geared to this one specific domain.
Why would they need to? A billionaire has plenty of money already.
From the bottom of the first page in the report:
Overall Gain – 1964-2019 .................................................... Berkshire: 2,744,062%
S&P: 19,784%

Huh? 2 million percent vs. 19k ?
> Rust interops with C seamlessly, doesn't it?

From someone who works in a mixed C + Rust codebase daily (Something like 2-3M lines of C and 100k lines of Rust), yes and no. They're pretty much ABI compatible, so it's trivial to make calls across the FFI boundary. But each language has its own set of different guarantees it provides and assumes, so it's easy to violate one of those guarantees when crossing a FFI boundary and triggering UB which can stay hidden for months.

One of them is mutability: in C we have some objects which are internally synchronized. If you call an operation on them, either it operates atomically, or it takes a lock, does the operation, and then releases the lock. In Rust, this is termed "interior mutability" and as such these operations would take non-mutable references. But when you actually try that, and make a non-mutable variable in Rust which holds onto this C type, and start calling C methods on it, you run into UB even though it seems like you're using the "right" mutability concepts in each language. On the rust side, you need to encase the C struct inside of a UnsafeCell before calling any methods on it, which becomes not really possible if that synchronized C struct is a member of another C struct. [1]

Another one, although it depends on how exactly you've chosen to implement slices in C since they aren't native: in our C code we pass around buffer slices as (pointer, len) pairs. That looks just like a &[T] slice to Rust. So we convert those types when we cross the FFI boundary. Only, they offer different guarantees: on the C side, the guarantee is generally that it's safe to dereference anything within bounds of the slice. On the rust side, it's that, plus the pointer must point to a valid region of memory (non-null) even if the slice is empty. It's just similar enough that it's easy to overlook and trigger UB by creating an invalid Rust slice from a (NULL, 0) slice in C (which might be more common than you think because so many things are default-initialized. a vector type which isn't populated with data might naturally have cap=0, size=0, buf=NULL).

So yeah, in theory C + Rust get along well and in practice you're good 99+% of the time. But there are enough subtleties that if you're working on something mission critical you gotta be real careful when mixing the languages.

[1] https://www.reddit.com/r/rust/comments/f3ekb8/some_nuances_o...
I was thinking, "Between Clinton and Trump, pass"
There is a third issue to licensing that dates back to ancient "law of strongmen" without even lofty claimed principles like divine right, let alone anything worth folllwing of free will; introducing a law that cannot be enforced only breeds contempt for the law. It is hard, expensive, and rare to covertly build infastructure. It isn't the case for software. Just blindly aping it would be draconian and silly.

At best it could be a license for specific safety critical applications but that would be dependent upon the licensed ones actually doing a better job at being safer which is harder for the first two reasons you listed.

Hell certifications are infamous for generally not being that career useful.
How in the heaven an array can sound like a graph?
Right, but the company might fail in year 5 or 6 after you're fully vested.
In some elections (at least, in the United States), there is write-in option (https://en.wikipedia.org/wiki/Write-in_candidate). If one feels that it makes no sense or difference, then, I guess, not voting is a feasible option. They also might consider running for a public office themselves.
Rust has singly linked, double linked ( in its minimal std library) and intrusive linked lists - all with APIs that guarantee a lack of memory errors and data races at compiler. I don’t know any good kernel developer that wouldn’t like those guarantees and I work in the Linux kernel professionally full time.