ble

There are safety regulations that require things roughly like, "to prevent harm to planes in the air and people on the ground, either control where your satellite re-enters so or make your satellite entirely out of components that are almost certain to burn up on re-entry".

As far as I can tell, there is no environmental regulation of how many kilograms of aluminum, silicon, etc. being added to the Earth's atmosphere when a Starlink burns up during re-entry.

cf. https://www.supercluster.com/editorial/forty-year-old-loopho... https://aas.org/about/governance/society-resolutions/atmosph...

Cool idea. Given that it transferred ~29 mb when loading, is it safe to assume that the actual page is doing some of the processing? Is the front-end just doing the HNSW or is it doing the mapping of stories or headlines into vectors, or am I totally off base?

Front-end downstream of clicking on a card doesn't seem to work correctly on every reload... but it works sometimes.

What kind of constraints can you add?

Could I put a unique constraint on property `id` of all nodes with label X?

Could I put a constraint that edges of kind A must always go from nodes with label X to nodes with label Y?

What kind of indices can you add?

Will SQLite use them when you do a Cypher query?

Will your Cypher query planner take them into account?

I couldn't compare it to other OSINT sources for satellites, but it was pretty good for looking stuff up when I wanted to.

Seems like a source that one should not generally take seriously (Tipranks) being syndicated by a source associated with an important name (Nasdaq) as part of a larger wave of articles about how some "pact", "treaty", or "contract" ended on a specific day.

Having done a little more digging, I could find lots and lots of pieces about this topic, but I could not even one coming from a recognizable journalistic source. (Far from the top of search results was a piece that seemed to have some value: it noted the wave of coverage of the purported end of this pact despite the fact that no such pact existed. It also identified a possible connection between pushing this story, which makes the dollar sound endangered, and attempting to promote cryptocurrency.)

Lots of HN commenters taking this at face value. To me, the overall situation looks like an object lesson in basic critical media literacy.

Links between satellites closing range near 2x orbital speed have two problems: - bigger doppler - the lifetime of the link is much shorter

The "routing in the mesh" slide? Definitely given where the satellites are in that picture some of the links would have to be cross-plane, it's just the whole thing looked so messy (even with it being geo-referenced on a globe) that I didn't know whether to consider it a "real routing example" vs a "notional routing example that we overlaid on the globe".

Sounds very cool that cross-plane links are doable, even if they have predictable complications compared to in-plane.

I would have thought that someone would make a big deal (have a press release, e.g.) out of successfully establishing cross-plane links, but maybe it just doesn't seem that impressive to people who already have good enough precise predictive ephemerides or satellite states to make those links in the first place.

My understanding of the state of the art of inter-satellite optical links is that they have only been used between satellites that are basically in the same orbital plane and in more or less the same orbit. That is, the angle from one satellite to the other changes very very slowly, so that the optics don't have to do much tracking -- and consequently satellites can only form an optical link with other satellites that are ahead or behind themselves in ~ the same orbit.

Cross-plane optical links would have a trickier tracking problem.

While there's no explicit mention of same-plane vs cross-plane optical links, I assume that the first time people have a public cross-plane optical link, they will make a big deal out of it. :)

The article also mentions that SpaceX would need to do further study before using laser links between satellites and ground stations-- this kind of optical link would require both more angular tracking and probably atmospheric correction as well.

the most amazing, most wirth's law project

My biggest beef with JSX is that what I might call the "most natural way" and certainly the "most concise way" of writing certain somewhat-complex structures in JSX often ends up being a huge mess. E.g. an element is some JSX elements with some code embedded, and the embedded code is returning some other JSX elements that have yet more code embedded in them, and the easiest refactoring to make the whole thing less gross is extracting functions that don't really deserve a name of their own.

I'm going to read that gist ( https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7d... ), but what do you dislike or hate about ES modules? From my own experience, they are extremely frustrating when tooling doesn't work well or at all with them.

Given that I don't do JavaScript or front-end for work, I mostly run into these things in hobby programming. Given that this is programming for fun, I can voluntarily cut myself off from all the libraries that use other module systems. In this happy little bubble, over time, ES module support has gotten better and I've selected tools / found ways to use tools that work with modules and I rather like it.

Perhaps because I'm less invested in the tools, I evaluate the situation of "tool X doesn't support ES modules" more like "tool X isn't great" and less like "ES modules are bad".

Perhaps it all stems from being a person who genuinely likes JavaScript, has a high affinity for standards, and a relatively low opinion (yes, I'm a snob) of the Node ecosystem?

Very nice looking diagrams for the amount of effort required to make them as a client of the library.

I love that it uses exactly 1 WebComponent. I love / am vaguely confused that it doesn't read the component's own DOM but instead gets the `.outerHTML`: https://github.com/franciscop/vector-graph/blob/master/index...

I guess that it means that the actual rendering gets fully decoupled from the live, but hidden DOM tree within the WebComponent and that live DOM tree doesn't really matter aside from first render.

The focus on "rational" value maximization on individual bets is doubly blind: - First, you and I might have different utility functions which are based on valuing outcomes differently; if utility functions are different, there may not be a single "most rational" choice - Second, a single bet is a single bet, but investing in a company or following a specific policy is more like staking a gambler to make a sequence of bets.

I appreciate this insight. A lot of the EA stuff really feels like Rationalists treading into philosophical problems where theologians and philosophers have been working for like, centuries, cocksure that everyone in the past has at best little to teach them.

shrug one arm of alphabet pushes through changes to Chrome without standards consensus, another arm of alphabet makes a poor bet on it.

hmm. doesn't stuff like this happen every time that chrome implements some interface but other browser vendors don't get on board with that specific version? doesn't this happen... kind of often? isn't it apparent that there's a risk of this happening whenever chrome implements something before there's standards agreement?

I [...] think it's more likely that some part of the Web Components tech stack will be removed from Chrome, Safari, and Firefox in the next 20 years, consequently breaking apps built with them, than JavaScript will change in a way that means a React 16 app I wrote 2 years ago will break.

Hmm. I think you've specified a bet you are likely to win, but one that's nearly meaningless. Perhaps if you fully lock down all dependency versions your React 16 app will not break, but that's a little more like running an old program in a VM or an emulator than "I can still work and hack on my React 16 app."

A more meaningful bet would be, "can you still develop on a React ZZZ app vs. can you still develop on an app built with web components."

If I got to pick the terms of the bet (to favor my viewpoint XD but also to make it more meaningful), they'd be "would updating a React app to catch up on N years of dependency updates be more or less effort than updating a web-components built app to catch up on N years of dependency updates"; if you keep your web-components built app from having a bunch of weird dependencies, I think the odds are very much in favor of the React app taking more effort to update.

Basically, betting on browser vendors to be less likely to break backwards compatibility than the authors of React.

Quick question to others who read parts of the introduction: does the writing style smell sort of LLM-ish to you?

Yeah, the author has committed to a stance without explaining why or how, beyond kind of provocatively suggesting that it's the only stance intellectually consistent with ruling out family punishment as a policy... as if he didn't outline his stance in several bullet points, and only 1 of those bullet points is sufficient to rule out family punishment.

How bizarre and ivory-tower.

I agree in general, but knowing that the author is a professor of Economics at George Mason University, I am less surprised.

My perception is that Econ department seems to have a lot of room for unusual ideas within the field and rather a lot of professors who hold forth or publish on topics that overlap to a variable degree with economics-- like how this post addresses questions of punishment and moral philosophy with what appear to be the tools of economics.

I would say that it's unclear; that announcement appears to apply only to the Keisan Casio user forum.

A machine translation follows:

The bulletin board will be abolished on September 20, 2023. Thank you for using our service. The bulletin board is a space where members can exchange information and opinions. Please respect each other's opinions and personalities, and post and reply with good sense.

Interesting. What personal experiences or survey data are you drawing on for these conclusions? All of what you say sounds like solid, believable inferences but I doubt most people are exposed to enough data about the interaction of family life and work to draw meaningful generalizations. (If you turn out to be a professor of quantitative sociology, my face will be bright red :) ).

I usually think of an at-work "politician" as somehow taking advantage of relationships or social forces.

What you describe sounds more to me like the ""10X engineer"" (with extra scare quotes for good measure).

Many people have been skeptical of the idea of the 10X engineer. One take is that if your normal engineers are less than 1/10th as productive as another engineer and all of them are merely human beings, there might be some common organizational problems that your normal engineers are all being stymied by. Another take is that your 10X engineers can only achieve their high level of productivity through taking on more technical debt than others understand or would tolerate, leaving messes behind for the eventual maintainers to fix.

I think the point is it's a technical structure that supports a very large organization's unified datastore, despite the fact that ownership of the structure of that datastore is decentralized and the responsibility for populating that datastore is maybe even more decentralized.

Very large organizations need technical solutions to organizational problems, especially when there are many loosely coupled teams interacting in one way or another.

why not use that one?

Taking any of the more accurate measurements of body composition requires effort, unlike BMI. It's easy and lazy and not yet acknowledged as an ineffective practice so doctors do it. It's also not always wrong, just because BMI and obesity do correlate.

It could be a holiday / hazing event for software engineers.

Is UTC as a system inherently unsafe or does it just expose unwary programmers to bugs, the vast majority of which are somewhere between benign and inconvenient in impact?

This article contains no instances of the word "test", which seems surprising but entirely in keeping with the author's observations.

Julia has no formal notion of interfaces, generic functions tend to leave their semantics unspecified in edge cases, and the nature of many common implicit interfaces has not been made precise (for example, there is no agreement in the Julia community on what a number is).

The Julia community is full of capable and talented people who are generous with their time, work, and expertise. But systemic problems like this can rarely be solved from the bottom up, and my sense is that the project leadership does not agree that there is a serious correctness problem. They accept the existence of individual isolated issues, but not the pattern that those issues imply.

It sounds like the cultural standard for writing libraries is, "works good enough for users like me" which should be good if you are using things the same way as the authors. Writing good tests for numerics is hard and grueling; testing numerics or numerics-like code is not nearly as fun or productive-feeling as using numerics to get shit done, so it all makes sense to me.

Read a little further down and the description has a different character: the Imperial Japanese Army showed, at best, an indifference to the lives of Japanese and indigenous civilians in Okinawa. Worse than the indifference, they propagandized civilians to believe that the Americans would rape, murder, and torture them and encouraged them to commit suicide or to launch suicide attacks and otherwise tried to maneuver civilians into harm's way.

At the time it probably did look like civilians were being turned into defensive soldiers- in the fullness of time, I think it looks more like a desperate and cruel army brutalizing a civilian population, sometimes pushing them into harm's way. I'd also presume that the treatment of the civilian population was worse for indigenous Okinawans-- maybe even today Okinawans can find themselves treated as 'not real Japanese'.

It's been a while since I read 'Embracing Defeat' but I recall its summary of the state of Japan towards the end of the war and a lecturer saying, in effect, that nobody had to invade Japan to cause the deaths of millions, the supply chain (Asian mainland colonies collapsing) / labor (men at all near military age gone to war and many of them dead or captured) / agricultural situation was so dire that the U.S. could have set a blockade and millions of Japanese would have died with 0 fighting.

The counter-argument to the necessity of the bombs is basically that the U.S. knew Japan could not effectively resist and though the U.S. might not have had a way of guessing, the highest levels of Japanese government were already in the process of discussing when and how to surrender right around the time the bombs were dropped. IIRC about the emperor's message of surrender, the bombs may have made it easier for the emperor to preserve face when surrendering, as such weapons make it easier to justify a surrender as a positive action.

What evidence is there, other than propaganda on both sides, that the Japanese were ready to use old people and children in a military defense?

Thank you for this context! I left the article curious to better understand the author's particular frame.