Kilenaitor

Having bugs is not the same as being non-deterministic.

I get the point that the compiler is not some pure, perfect transformation of the high-level code to the low level code, but it is a deterministic one, no?

Same! Would love any resources. I'm interested more in making models run vs making the models themselves :)

+1 Leap takes a second to get used to but I love it so much. Even if you don't get to the precise character you want, you can get so close enough that normal motion commands get you the rest of the way.

I do change the bindings, tho. I have 's' leap forwards and 'S' leap backwards.

Neither teachers nor nurses only work 40 hours and no overtime. :')

Definitely something that requires social/interpersonal skills though will be the thing that winds up being AI immune. Humans are social creatures so I assume there will always be some need for it.

I'm Christian, so slightly different context going in, but I also found it profound. I've been to other churches and cathedrals (including the Vatican!) and they feel sterile by comparison. Stepping inside to the sight of a towering forest of stone and dazzling light is truly breathtaking. It made me genuinely emotional.

It's nothing like I've ever seen before so I'm surprised by the comments at the end of the article that make it seem like its originality has waned over the years. You can feel the conviction and passion that have been poured into it for over a century.

I can't wait to visit it again. I really love it.

Sure. I guess caveat I haven't used Mosh in a while, so maybe things have changed.

Mosh paints the screen, meaning no native scrollback. You have to use a multiplexer like tmux to get it. But ET has native scrollback. This is the biggest one for me.

Couple years ago I was on a more limited network that constrained usage of UDP which Mosh uses. ET uses TCP.

Mosh buffers inputs locally first which gives it the appearance of low latency but that illusion breaks when there are network issues. I prefer ET, even tho it can appear slower, since network issues are more obvious and I can troubleshoot them. But on a good connection, they're indistinguishable to me.

Those are three. There may be more. Honestly they are probably still more or less interchangeable for most. No reason to switch if you love Mosh.

I have replaced it with Eternal Terminal: https://github.com/MisterTea/EternalTerminal

But I don't know how widespread that is.

To elaborate with some context: large sites do this to avoid hammering a small site if posts containing the link go viral.

Like imagine the thumbnail were fetched every time a link appeared in someone's Facebook/Twitter feed. That could be tens of millions of hits easy.

Also has a way better headline heh

God. Thank you.

> But the last fucking thing I want to do is delegate all the code writing to someone or something else

I talked about this a few days ago with coworkers and I phrased it almost exactly this way. I want to be an IC. I want to do the work. Becoming a manager-of-one to funnel all my work through would deprive me of genuinely my greatest joy in life.

I'm envious you managed a few good decades. I'm almost eight years into what has been my dream profession and to see indications it's going to morph from writing code into telling a robot to write code is just so demoralizing. I could have done this for decades. I wanted to do this for decades.

I used to mispronounce Redis too and I fully fault the "MongoDB is web scale"[0] video for that.

Glad I'm not alone heh

[0]: https://youtu.be/b2F-DItXtZs

The individual scientists' rights to publish uncensored papers??

The firing is not motivated by the ratio. It's not a handcuff saying you must find x% of the workforce to fire.

It's setting a bar that when evaluated on a curve a certain percentage of your employees wind up being below that bar. You derive the ratio from how aggressive you expect your bar to be.

But no one is saying you need to fire people. They're saying they expect a certain amount of lower performers and if they don't see it, they want to know reason. But it also only manifests at much higher populations than an individual team. Totally possible a small enough team has everyone >= meeting expectations.

I enjoyed this post since this is exactly my approach to improvements: imagine the magic want solution, find the deltas between it and current state, code the deltas.

At work I often get tapped to work with folks who struggle with "Better Engineering" ideas (codebase improvements with an eye towards increased productivity). Usually it's just people being unable to come up with any improvements.

I always prompt them: 1. "Is this the best codebase you've ever worked in?" and 2. "If you were to rewrite this from scratch, would it look exactly like this?".

It's amusing how often those two questions trigger a light bulb moment. I of course follow up to ensure their ideas are actually good and grounded (no "let's convert the monolith to microservices") but it does wonders for inspiration.

Not OP but one that is usually contentions is the ability to act as an SMS client. Facebook's Messenger can or at least used to be able to do this on Android. It cannot on iOS.

Courts are the ones that interpret them. That's why Apple's argument is made to an EU court, not legislature.

Any specific book of his you recommend? "On War" seems to be the one that popped up on a search but wanted to confirm. Sounds like an interesting topic.

Ah yes. Just realized the author linked to its wikipedia page. Whoops.

Why would Unicode bother consolidating code points like this...? Not like it's short on space.

I've switched over to using `sl` commands. Sapling is installed on ODs by default. Main change I had to get used to was `up(date)` became `goto`.

> Launched by Google in 2019, the App Defense Alliance was established to ensure the safety of the Google Play Store and the Android app ecosystem by focusing on malware detection and prevention. With a growing emphasis on app security standards, the Alliance expanded its scope in 2022 and is now the home for several industry-led collaborations including Malware Mitigation, and App Security Assessments for both mobile and cloud applications.

I'm confused on your phrasing of "they explicitly never will be."

Those prototypes, of course, aren't going to themselves be shipping. But they are for R&D and to provide example of a nascent technology that one day should end up in a consumer product.

You absolutely can disagree with the approach of showing this too early or not trying hard enough to incorporate this into an (albeit expensive) consumer product today/soon.

But my read is Meta wants this stuff to one day be in consumer headsets. Just not there yet.

Internal Phabricator isn't even really Phabricator anymore. In fact, the name changed to just Diffs. I'm pretty sure its entire codebase has been rewritten, at the very least into Hack from PHP. They have a custom API; not Conduit. Etc.

So, no. They wont support Phorge. They really never supported open-source Phabricator after Evan left and made it his own with Phacility.

Lmao that is ridiculously unfair since you're starting with a near-universally agreed bad thing.

Better analogy augmenting yours: just cars. Accidents between cars or cars and pedestrians kill lots of people every year.

This works with every tech. Phones have made it easier to coordinate crimes. Printing press and even televisions made mass propaganda possible. There are always tradeoffs.

This might seem like a silly question but could you give me an example use-case?

I'm struggling to think of a context where we basically want to create timestamps for things that happened in the past. Especially things that we want to dynamically localize rather than e.g. just store as a straight up timestamped string.

Wait if you just need dates, why not store dates?

I was under impression unixtime is best for timestamps. But no reason to store something like a birthday using them; just do a string YYYY-MM-DD?

How has it been a regression for the web?

Meta discontinued the Portal line

https://www.theverge.com/2022/11/11/23454019/meta-portal-sma...

Zuck actually posted about this on his Facebook[0].

Short answer is the first layoffs (seemingly) were rather random as far as who was affected. This new round is a lot more deliberate by

1. Cutting projects/efforts that don't make the cutline

2. Letting go the surplus of people previously needed to execute on those projects

> Since we reduced our workforce last year, one surprising result is that many things have gone faster. In retrospect, I underestimated the indirect costs of lower priority projects.

> It's tempting to think that a project is net positive as long as it generates more value than its direct costs. But that project needs a leader, so maybe we take someone great from another team or maybe we take a great engineer and put them into a management role, which both diffuses talent and creates more management layers. That project team needs space, and maybe it tips its overall product group into splitting across multiple floors or multiple time zones, which now makes communication harder for everyone. That project team needs laptops and HR benefits and may want to recruit more engineers, so that leads us to hire even more IT, HR and recruiting people, and now those orgs grow and become less efficient and responsive to higher priority teams as well. Maybe the project has overlap with work on another team or maybe it built a bespoke technical system when it should have used general infrastructure we'd already built, so now it will take leadership focus to deduplicate that effort. Indirect costs compound and it's easy to underestimate them.

> A leaner org will execute its highest priorities faster. People will be more productive, and their work will be more fun and fulfilling. We will become an even greater magnet for the most talented people. That's why in our Year of Efficiency, we are focused on canceling projects that are duplicative or lower priority and making every organization as lean as possible.

[0]: https://www.facebook.com/zuck/posts/pfbid024Q9h2gvnYGmU6czAH...