skysight-inc/HackerNews huggingface dataset:
Good point. So there is more to it, which I didn't consider before. As I understand [1], the client uses the public key of the key pair used by the SNI to encrypt the SNI value, additionally to any TLS encryption. Only the actual SNI has the private key to decrypt the SNI value.
The client must look up the public key in the DNS (I guess at least if it doesn't know the key already, which it could have in the cache).

This whole thing is still a draft RFC [2] and currently called encrypted client hello.

What I don't get: The client will have to disclose, which public key it used to encrypt the client hello / SNI value. But don't we know "all" the public keys from the certificate transparency logs? Usually a public key is only valid for a limited set of domains, so it would be easy to associate the public key used for encrypting the SNI value with the relevant service. Just look up the public key, read it's SAN or CN, and you pretty much know the SNI value. Or at least the service, which might be good enough. What am I missing?

[1] https://blog.cloudflare.com/encrypted-sni
[2] https://www.ietf.org/archive/id/draft-ietf-tls-esni-15.html
At the risk of going "no true Agile" on you: There is nothing about agile that requires spending 4 hours a day in meetings. You're suffering (I believe that is the correct word) under an agile-in-name-only bureaucracy.

Agile can be done well. I've seen it, and it was amazing. I've also seen "agile" implemented where the number of meetings (and the number of forms) keep going up. But the existence of the fake does not disprove the existence of the real. It just means that you have to be very wary of anything bearing the name.
Because there isn't a market for home CO2 scrubbers.

Here's a company that sells them.

https://www.alfaintek.com/products/air-scrubber/
There’s pros and cons to both approaches. At the end of the day the framework you use won’t make up for serious deficiencies in the product/organization/tech stack. But you can’t ignore benefits with agile over waterfall of delivering small incremental updates quickly, major issues and defects bubble up quicker and can be address before you sink too much time/effor into the product.

This is similar to the lean approach in manufacturing that has been very popular over the past ~20 years.
> Why is Prop 13 welfare?

When I talk to my dad about Proposition 13, the one thing he remembers about the ads is that it was supposed to keep widows and single moms from losing their house. In other words, he thinks of it as an entitlement program to help poor residents. But as the article points out, it is a subsidy not for the poor; it is instead a subsidy that regressively targets property owners (including landlords and commercial properties) at the expense of recent buyers and non-property owners (including widows and single moms who do not own an appreciating property).

> This kind of logic results in net loss to citizens:
> https://time.com/5530386/aoc-amazon-new-york-hq2/

I agree with you that it is unfortunate that politicians such as AOC conflate economic development incentives with welfare. That has nothing to do with Proposition 13, which is not an incentive program. In fact, the incentives that Proposition 13 does contain (to avoid developing or selling which trigger reassessment) perversely exacerbate the housing scarcity that it was supposed to alleviate.

> Also, why are those against Prop 13 the most silent (usually) on corruption in the state?

Your final question seems to imply that opponents of Proposition 13 are a special interest who are ok with corruption. I disagree. I think an impartial observer can analyze the state’s largest entitlement program and complain about the obvious regressive aspects of it.
My experience with Agile has been a little bit meeting heavy though, the rituals etc.

It’s a really hard balance to get right and Agile easily ends up turning into a lot of pointless meetings teams feel like they need to have because that’s part of the manifesto they prescribed too.

I’ve also found lot of counselling and explaining starts happening when sprints aren’t going well or people become fatigued.

We could argue it’s not an Agile problem, like everything it’s susceptible to a lot of problems which we like to gloss over because it’s convenient to do so and those who advocate for agile haven’t bothered to revise and improve on the original manifesto to address these weaknesses.

the Agile manifesto is a bit like a bible in that sense.
Twitter Blue 'probably' coming back end of next week, Musk says
As a member of the younger generation, I would give you a hard pass for holding such a sentiment.
Yes, it is. Bands at Amazon (where the comp was lower compartively) were raised to at least compete with the other FAANGs, but that was before the layoffs/freeze situation when they thought they still had to do that. Comp is majority stock at most of these companies, TC has gone down by definition of stock dropping, and places like Amazon assume growth in fact when calculating your target comp and what to allocate. Refreshers are very unlikely to make up for this drop since they don't have to (supply/demand).
Environmental drivers of the first major animal extinction
No one will get far trying to have a debate here. Agile is both poorly and conflictingly well-defined and its adherents seem to lean on "no true Scotsman" defences when given an example of massive inefficiencies an organization that claims to do it. Whatever you are doing is "agile" if you are performing well and not if you aren't. Also the idea of some pure waterfall is nearly as much of a strawman as the ethereal agile. Measuring performance is also quite difficult. Is it meeting internal or external deadlines? Providing consistent and accurate estimates of time and effort? Providing software of sufficient quality regardless of those measures? Do what works for your team. Make changes if it isn't working.
I’d argue that your previous team was an agile team. My team also has 1 meeting a week where we go over the work for the week, and ask any questions we might have. We do retro like once a month but not always. Depends if we have anything to talk about. We don’t do any Agile™ stuff. I’d say we’re closer to an extreme programming team which has a lot of influence on capital A Agile. At any rate I agree that the type of top-down Agile forced on teams is not good for teams. The only people I can see benefitting are directors. The style I work in keeps everyone but my team in the dark and unless you have a good track record exceeding expectations you might be forced into Agile™
Not an Agile extremist. If done effectively agile is a simple framework for aligning on work, having some cadence for updates and accepting or rejecting work based on quality and alignment.

I personally dislike when it's made significantly more complex. High-performing teams can work in a standard Scrum framework or they can customize agile to suite their needs.

If you're spending hours a day in meetings, you're not using the framework correctly. In a fell-functioning team, you'll spend 5-10min max doing some form of standup, in some teams this is even async so no daily meeting. That leaves one planning meeting every two weeks and one review meeting to see how you've done.
Apple would purchase the entire output.

As I understand it, TSMC has advanced, exclusive fab technology. Only they can do what they do. It’s very interesting that China “let” them set up a fab in the US, let alone the most advanced fab.
This seems like a whole pattern of attacks that can be defeated with a single counter and random-early-drop.
Commenting this on every post without explaining anything doesn't really do anything but confuse. And the more you do it, the more it appears that your definition of "agile" would be the outlier here. Though as many will tell you, the definition of the process is quite varied.
The article's title refers to "code quality", but the word "quality" never appears in the body. The article is about the number of bugs, so I think a more appropriate term is "software quality" (more specifically "software functional quality", per Wikipedia; but of course it would be clearest if the title just said "number of bugs").

To me, "code quality" means something very different (well-written, readable, maintainable, etc.; Wikipedia calls this "software structural quality"). According to this definition, "code quality" may be correlated with the number of bugs (hopefully with a negative correlation!) but the two are very different things.

And I'd like to boost @kragen's comment (https://news.ycombinator.com/item?id=33566329#33579042, toned down):

> haldar's summary is ... incorrect ...

> the paper finds that faults (and wmc (methods per class), cbo (coupling between object classes), response for a class (rfc), number of methods added (nma), etc.), correlate to class size (non-comment source lines of code), not program size
A Simple Overview of Authentication Methods for Kubernetes Clusters
Odin has poor support for Windows:

https://github.com/odin-lang/Odin/discussions/2047
I apologize but I think I'm missing what you're saying.

I'll just elaborate and say the key to what I said is making it habitual by adding into something you'd be doing anyway. The exercise bike is great because you can watch TV, read, or even play some types of games or other sedentary activities you may be doing anyway.
The way you actually have to do it is trawling through git repos to find an old version of Gwydion, bashing at it for a while, and maybe getting it to compile on modern platforms. Look for 2.4, then rewind, then pass a config flag, and a few more steps.

I wouldn't call Dylan thriving, unless you're a Windows user that really doesn't care about bootstrapping your language.

It's alive though, in the same sense that Miles, the dog that Segall froze and then brought back to life in 1987, was alive. Brain damaged, but alive.
> 4 out of 8 hours every day in meetings

Does not sound like agile. Standup is a 15 minute affair, planning & retrospective a once every 2-week (however long your sprints are) event 1-2 hours long. That's all. Roughly 4 hours for every 80 hours of work.

Whatever you have going on there is probably a wild detour off SCRUM inflicted by agile consultants, which seems to be very common these days.
The number of Agile apologists in this comment section surprises me.
How is any of that related to a video showing 6 people dying? This is, literally, like saying you’re into cars, so you watch fatal car crash videos. Sounds like complete nonsense. It’s been flagged to death, so the sentiment wasn’t shared.
IMO all agile should be about is making sure everything is easy to change. Make code that's easy to change. Make procedures that are easy to change.

And actually make change and find what works.
You're part of the team. have you talked to anyone else about this? Either you can complain online, you can leave the team, or you can start trying to build some consensus with teammates and start making incremental improvements, if management is receptive. It sounds like you needed to let off some steam too! :).
Common Lisp is multi-paradigm and can be written to write functional code. It is the direct descendant of LISP which was the first functional language after all. Yes, Scheme and the like are more functional but CL is still far more functional than most other languages.

Imperative relates to coding style - I can equally write imperative or recursive code in Java.
>There is a reason Elon Musk just fired half of Twitter.

Unfortunately this heavily detracts from an argument that might otherwise have merit.

>He clearly put 44 billion dollars where his mouth is and told you that your pointless meetings don’t matter and they don’t need it to build quality software.

He's made a mockery of himself already and is well on his way to imploding the platform. Moreover, how much software quality do you think is going to come out of Twitter now that employees live in day-to-day fear under arbitrarily extreme deadlines, while understaffed at that?

The situation is a joke at this point and has more to do with Musk's mental instability than it does Agile, as much as I loathe some of its uses and implementations.
> Warning: Unpopular opinion ahead.

Do we do that here? Should we?

> Now please explain to me what part about spending half the day in meetings rather than writing code is actually “high-performing”

I'm not sure what agile methodology you're using that ends up with this many meetings, but Scrum, a popular agile framework, recommends only a few and the daily one is supposed to be relatively short.

> Below is an open-challenge to any person or organization

Define your metrics and make sure your printer has toner.
> My current company spends 4 out of 8 hours every day in meetings.

Be the one in your organization to solve this problem. Start with your immediate team. Doesn't have to be this way.

Some 0.02:

1. Sprint planning is slowed down by diving into technical details. Leave that for another time.

2. Retrospective doesn't need to be more than 15 minutes. Sometimes there is nothing to discuss. It may help to have participants populate an issue board before the meeting, so retro can focus on prioritizing and addressing. I use a mattermost channel called "Retro" where devs can add an issue they are having and all the other devs can vote with a thumbs up. Before retro I sort them from most thumbs up to least. Devs can reply to issues with a solution or an offer to help ahead of time so we don't have to discuss the issue in the meeting.

3. Don't let the backlog grow to big. Groom it regularly with tech lead and PO.

4. Maintain an open list where people can populate any "parking lot" items ahead of stand up. I use a mattermost channel called "Parking Lot" and I look at any chat items added on the day of standup. Devs can reply and sometimes solve issues before stand up.

5. Structure your stand up where everyone says: task # from jira/gitlab issues/etc they are working on, any open MRs that need to be merged in, and answer the question: do I have any impediments preventing me from working. The last item is a quick "yes I have impediments" or you don't say anything. Leave the details of the impediment to parking lot. Allow everyone to leave after the last member speaks. Anyone who has a vested interest in a parking lot item or impediment from another team member can stay.
I have met so many developers that have the mistaken notion that doing things other than programming is somehow far beneath them. They are indignant that the business would hire people to check in on what they are doing day to day. But I see it the other way. It’s something which developers have a) brought upon themselves through myriad issues ranging from poor communication to outright laziness, and b) have provided no better alternative to, and c) have tolerated in high enough numbers that it is now the defacto workplace standard.

As for myself, I don’t like all the agile rituals and ouija board crap, but I also don’t mind explaining what I am doing to clueless people a couple hours a week. Things could be much much worse. We could be paid a lot less and have way worse working conditions.
> Even the heaviest weight version of this I can imagine (daily 30 min standups, 1 hour planning, 30 min retro, weekly sprints) adds up to 4 hours total for the week. So what you're describing is 80% something beyond that.

Pivotal Labs, well known for "doing Agile right," spends the entire Friday doing no work every week.
Exactly. When people say “agile sucks!” I always want to ask “compared to what?” Engineers who say that they meet for a few minutes once a week and then everyone somehow just knows what to do… frankly I call bullshit. That may work at a 5 person startup, but as soon as you have 100 people, you’re going to have a lot of programmers writing code who are sure they know what’s best but in fact have no idea how their work aligns with the company’s overall goals.
Honestly man, maybe your company sucks at applying agile methodologies.
I didn't say I couldn't believe they were using rails. I knew very well that Github was originally written on Rails. I was surprised to learn today that the frontend was still rails. The narrative in my head was that, like Twitter, which started as a rails app and eventually outgrew it, Github had abandoned Rails some years ago.
>they are hypothesized to improve immune response to tick-borne disease, such as Lyme.

I'm not sure if I'm reading you right, but would this also mean that people who already have Lyme Disease might see an improvement?
Except that both can be true. A few millwats can reach across town, or across the world. The original claim was that "weak signals don't go very far", or some such.
> because that would be an eminently stupid decision to make about an institution that will be about as relevant to American life as drug store soda fountains in 10 years

Malls lasted a long time. But why is that a stupid decision? Let's not even say "decision" though, let's just say every mall offered to rent the hallways out to the local government at a nominal fee, nothing else changed, no lock in. Wouldn't that be a significant improvement?

And when I said earlier, tens of millions of users, if github wants to be small again then it will go back to the bottom of the sliding scale.
I totally agree. I used to be highly engaged and high performing. Agile and sprints are soul crushing for high performers. They reduce risk for managing underperformers, I get it. But it's such an artificially slow pace and so much mind numbing process. It's like being trapped in Office Space. You can't take true ownership of anything that's distributed among a bunch of different people and spreadsheets. I thrive on ownership.
The way your organize work needs to be appropriate to the work being done, and to the individual people involved and their relationships.

Sometimes this will look like one of the named methodologies under the "agile" umbrella, sometimes it won't.

Sometimes you get a team that will do fairly well regardless of which methodology they get stuck with. Sometimes you get one that will do badly regardless of methodology.
Economic theory can often be inaccurate for this. For example, we predict that if a state has a minimum wage and a neighboring state doesn't, unemployment in the state without minimum wage laws will increase, because people will cross the border for the higher salaries. Turns out that's not the reality. You have to look at real work "controlled" experiments to verify the theories.

Salaries, like real estate prices can be quite static, except when it's a bubble of someone trying to sell something to the next sucker. If someone can't hire someone at a specific budget, they're more likely to not hire anyone instead of increasing the budget. Similarly, if someone can't get the same job at the same salary, they end up getting other jobs. We see cases where actors without work become waiters instead of taking a poorly paid acting role.

There's probably some point of desperation, but even then, some people are likely to take jobs at shitty startups that work them 12 hours/day, 6 days/week than take a pay cut.

My prediction is average salaries will go down very slowly. Probably 0%, a decrease compared against inflation. Maybe around 5% this year. What will most likely happen is work conditions will become worse and benefits will be cut. Many people will simply change careers. It might be like the telco boom, where people with a telco degree and experience just ended up making apps in 2010.
That's a lot to unpack.

But I agree with your general sentiment - As currently practiced, Agile generally involves a lot of ceremony before actually building, with many rounds of collaborative planning and risk management on every decision. It's morphed into something completely different than the original definition...

We have come to value:

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
These predictions don't even take into account factors like sea level rising by meters. Think about the demographic impact of coastal infrastructure going underwater and having to be rebuilt and reconnected to different roads and railways, farmland going underwater and permanently lost, many million of people becoming homeless also in first world countries, lack of food and clean water. Help yourselves to add more to the list. If enough of this happens fertility rates are the least of the problems.
I don't think we disagree :) If you're going for full accuracy you morally need barriers all over the place. If have TSO in your chips that makes things far easier, alternatively you can do stuff with RCpc if your hardware supports it. Otherwise you get stuck with fences everywhere, or you force your hardware into TSO compliance mode (read: turn off all the other cores) and that sucks.

The other option is you relax on the "required fencing", with the assumption that most accesses do not actually exercise the full semantics that TSO guarantees. Obviously some synchronization does matter, so you need heuristics and those won't always work. My understanding was that XTA has some of these, with knobs to turn them off if they don't work? You probably know more about that than I do. In iSH we play it even more fast-and-loose, with all regular memory accesses being lowered to ARM loads and stores, and locked operations to whatever seemed the closest. It's definitely not production-grade but we have shockingly good compatibility for what it is.
Well, I might be pretty inexperienced, but in our project management class it was explained pretty clearly that agile (=lots of iteration) works best for projects with lots of unknowns (especially with a high risk of unknown unknowns), while waterfall (=no iteration) works best for already well-trodden projects in well-known conditions.

(We were too busy for an agile class or project, only got waterfall, since it is simpler.)
I want to give you a thorough answer but I've a lifetime of bad experiences with that airport and I'm on my phone where I can only type for so long before my thumbs hurt.

My issue is not so much about the physical design of the airport (although I do have beef there) but more the human institution of it. Suffice it to say that I have missed way too many international connections there due to kafkaesque bureaucracy, and they've lost way too much of my checked baggage. It's also an especially bad place (relative to other major European air hubs) to have a member of your travel party in a wheelchair.

However, they do have an on-site high speed rail terminal and I think that's super awesome and deserves major kudos.
Thanks for this, it brings back memories. I did a similar search of rules way back when but much less systematic.

HighLife and Day and Night were two rules that I found and shared with a private mailing list that Conway was on. He was very complementary as I recall, I was elated.

Day and Night came from a deliberate search of the subset of rules that were self-inverse. For example the inverse of Life is a rule where the background is normally black and objects are white. But some rules have a symmetry where objects exist as well as their inverse.

Likewise HighLife came from a search of rules that supported the Life glider - there’s a subset of neighborhoods that aren’t involved in the glider evolution and can be set to other values. I noticed HighLife because it has a naturally occurring replicator, something very rare.