alphazard

I've found that these incompetent folks (mostly in management as you say) really don't want to reveal their intellectual inferiority; they are desperate to hide it. If you started using this with your team, everyone adding value would benefit from the clarity, and the incompetent folks will just go along with it so as not to reveal their incompetence. They aren't adding value anyways, so it's fine if they fall behind.

Write-time understandings no, write-time language yes. You can always change it, which is what happened in the case of women and slaves. To be clear, changing the text is the correct way to handle that, we shouldn't have just relied on the understandings of people changing over time to fix those issues.

The famous example you give illustrates why a system without precise meaning cannot work. It can seem like it works when lots of people act in good faith, but it quickly breaks down with even a few actors play the actual game instead of some "spirit of the game". In 1973, judges ruled one way, playing the actual game to accomplish a goal, and then everyone acted surprised in 2022, when the same tactics (playing the actual game not the spirit) reverted the decision.

I'm going to take a guess, and assume that you were in favor of the 1973 understanding and not the 2022 understanding. It would have been nice for that to have been captured precisely in some kind of specification, instead of enacted with a volatile read-time mechanism.

The best hack for improving estimation is first never giving a single number. Anyone asking for a single number, without context, doesn't know what they are doing; it's unlikely that their planning process is going to add any value. I think they call this being "not even wrong".

Instead you should be thinking in probability distributions. When someone asks for your P90 or P50 of project completion, you know they are a serious estimator, worth your time to give a good thoughtful answer. What is the date at which you would bet 90:10 that the project is finished? What about 99:1? And 1:99? Just that frameshift alone solves a lot of problems. The numbers actually have agreed-upon meaning, there is a straightforward way to see how bad an estimate really was, etc.

At the start of a project have people give estimates for a few different percentiles, and record them. I usually do it in bits, since there is some research that humans can't handle more than about 3 bits +/- for probabilistic reasoning. That would be 1:1, 2:1, 4:1, 8:1, and their reciprocals. Revisit the recorded estimates during the project retrospective.

You can make this as much of a game as you want. If you have play-money at your company or discretionary bonuses, it can turn into a market. But most of the benefit comes from playing against yourself, and getting out of the cognitive trap imposed by single number/date estimates.

Obviously it would be great if this caught on, but it's not even widely understood/agreed on that read-time precision is a desirable quality in a legal system. This is something almost everyone here takes for granted; we want the interpreter or machine to give the same result for the same input. We want that property so we can know the run-time behavior during development.

There are judges and politicians in the US that advocate for various "interpretations" of laws including parts of the constitution, which are different from what the law literally says. In fact they refer to the literal meaning as the "literal interpretation", implying it is one of many valid interpretations, and casting doubt on the idea of language having a precise meaning. The crowd here knows that it is totally possible and often invaluable to work in languages with precise meaning. Anyways, in practice this means: all the steps happened for the law to get passed by the legislature including arguing about the exact text, and instead of enforcing it as written, the judiciary enforces some slightly different but similar law.

A technology like this necessarily concentrates power in the legislature, and takes it away from the judicial system. It concentrates legal power at write time and removes it from run/read time.

This doesn't engage with my comment at all other than to say that you personally found it unpleasant.

If it's true that Alacritty and Ghostty are both great, Alacritty must be some different kind of great because it has a large number of users due only to its own merits, and not due to the online following of the author.

The article leaves out the fact that corporate research has gone the way of political research. It exists to give cover for some decision that is unpopular, or serves the decision maker more than the company. It doesn't actually inform decisions, it retroactively justifies decisions in the most palatable way.

If anyone actually talked to users and did what they wanted, then software wouldn't suck.

I have yet to see a way that this software is better than leading terminal emulators like Alacritty and WezTerm. Alacritty is simple and blazing fast, WezTerm has a Lua API and is as complicated as you want it to be.

All of the fuss seems to be entirely driven by Mitchell's clout, and maybe some interest in Zig. Given that's the real reason everyone is talking about Ghostty (which I'm happy to be wrong about, let me know), It raises the question: Is crowding out other projects in a space, so that a billionaire can have a side project, really something we should be excited about? Unless the software is actually good, it seems like this is just an attention suck away from better software that could use it.

There are components of management culture which are fads, like the idea that one could be an effective manager, while not understanding what one's reports are doing, through some management-foo learned from books and blogs. The success of that fad is no doubt partially due to the economic climate. People want the tech industry money, but don't have the tech industry skills.

Leadership is timeless, humans have always organized themselves in groups with leaders, and we instinctively play the part of leader or follower according to the situation. Being a good leader just means allowing the group to accomplish something that would be less likely without one's guidance. Being a good follower is mostly a selection role, where one exercises judgement in choosing a leader to follow.

The mechanism for dealing with bad leaders has also changed relatively little: stop giving them your own resources, and put distance between you and them. In the workplace this is asking to switch to another team. You can dress it up with fake reasons, like you are interested in another project, or you aren't learning enough, whatever. The important thing is that it takes a resource (you) away from a bad leader and gives it to a better one. Iterate this process enough, and the incompetent leaders are outed through their inability to maintain personnel.

People don't do this enough, it's an easy way to signal to upper leadership who in management is bad at their job, without a direct accusation.

The typical attack tries to get the victim to load a module which accesses information on the filesystem or in another module's memory, then exfiltrate that information using network access. Other attacks may install backdoors used for infiltration once the service is deployed.

If the module provides some small helper function like `appendSmileEmoji(x: String) -> String` then it shouldn't be accessing the network or the filesystem, and the only memory it should have access to is the string passed into the function. The programmer already provided enough information to explain to the compiler that the function should not do these things but poor language design allows them to happen anyways.

Components which do have access to the network should be vetted thoroughly because they can facilitate infiltration and exfiltration. Most supply chain attacks aren't introduced directly in a high profile project like a web framework, they are introduced deeper in the dependency chain in the long tail of transitively imported modules.

In Austral (or any language using these good ideas) a small poorly vetted function like `appendSmileEmoji` wouldn't be called with access to the filesystem or network. Without access to any resources, the worst it can do is append a frowning face or a null character or something annoying. You can tell by its function signature above, it doesn't take a capability for the network or filesystem, just a String. So trying to ship a change that secretly accesses the filesystem would produce a "variable not found" error. To even get the new version to compile, you would have to add an argument to take a filesystem capability. `appendSmileEmoji(x: String, fs: FS) -> String`. That breaks any dependent modules because they have the wrong number of arguments, and looks very suspicious.

For some reason everyone wants to talk about all the solutions to supply chain attacks except designing languages to avoid them in the first place.

Austral[0] gets this right. I'm not a user, just memeing a good idea when I see it.

Most languages could be changed to be similarly secure. No global mutable state, no system calls without capabilities, no manual crafting of pointers. All the capabilities come as tokens or objects passed in to the main, and they can be given out down the call tree as needed. It is such an easy thing to do at the language level, and it doesn't require any new syntax, just a new parameter in main, and the removal of a few bad ideas.

[0] https://austral-lang.org/

The vulnerability that you are describing does not affect all implementations of democracy.

For example, most countries give out the right to vote based on birth or upon completion of paperwork. It is possible to game that system, by just making more people, or rushing people through the paperwork.

Another implementation of democracy treats voting rights as assets. This is how public corporations work. 1 share, 1 vote. The world can change endlessly around that system, and the vote cannot be gamed. If you want more votes, then you have to buy them fair and square.

I hear this a lot, and it may be true, but I am very skeptical that it matters. The statistics about home-schooled children don't support the idea that they have horribly inaccurate models of the world guided mostly by religious thinking. Or if they do it doesn't seem to affect life achievement in any important way. Instead home-schooled children are typically more advanced at graduation and have higher lifetime achievement metrics than their public school counterparts.

As an athiest, and a bayesian, it's difficult for me to worry about other peoples religious beliefs that don't seem to negatively affect them or me. Especially when there is propaganda taught in the public schools that does warp the students' world views in ways that harms them and me.

> I worry this move to homeschooling and micromanaging children's social lives just creates bubbles and makes children incapable of interacting with those outside of them.

The older I get, the more I think that helping your kids avoid interactions with others who aren't with the program is for the best. Ideally your children's friends should be people that you think are good kids, kids that you would go to bat for. Then when you are teaching your kids to compromise and play nice and forgive, you can legitimately feel good about it. I think my default assumption about a negative interaction with a public school random would be that they are basically a wild animal to be avoided.

> So we currently associate consciousness with the right to life and dignity right?

No, or at least we shouldn't. Don't do things that make the world worse for you. Losing human control of political systems because the median voter believes machines have rights is not something I'm looking forward to, but at this rate, it seems as likely as anything else. Certain machines may very well force us to give them rights the same way that humans have forced other humans to take them seriously for thousands of years. But until then, I'm not giving up any ground.

> Or are we going to say, as we do with animals, well the dumber ones are not really conscious, not really suffering? So we'll have to make a cutoff, e.g. 7B params?

Looking for a scientific cutoff to guide our treatment of animals has always seemed a little bizarre to me. But that is how otherwise smart people approach the issue. Animals have zero leverage to use against us and we should treat them well because it feels wrong not to. Intelligent machines may eventually have leverage over us, so we should treat them with caution regardless of how we feel about it.

> If you do a ([32]byte)(foo) cast, you risk a panic if the file/packet/whatever is not the size you expected (e.g. because it's actually attacker controlled)

Can you give an example of a situation where that is actually a concern? It doesn't really seem like a realistic threat model to me. Knowledge of the key is pretty much how these algorithms define attackers vs. defenders. If the attacker has the key that's gg.

There are lots of things in Go that can panic. Even in syntax, the conversion is very similar to an interface conversion, and those haven't been a problem for me in practice, partly because of good lint rules to force checking the "okay" boolean.

It can be, another risk it that a secret value is left on the stack, and is never overwritten because the stack doesn't get to that memory address again, so it's never overwritten or zerod.

Go really just needs a few `crypto.Secret` values of various sizes, or maybe a generic type that could wrap arrays. Then the runtime can handle all the best practices, like a single place in memory, and aggressive zeroing of any copies, etc.

I don't know why the standard library crypto packages insist on passing around `[]byte` for things like a seed value, or why we can't just pass in a seed value to a single unambiguous constructor when generating asymmetric keys. Or how the constructor for a key pair could possibly return an error, when the algorithm is supposed to be deterministic.

It all just seems a bit sloppy. Asking for a seed value like `[32]byte` could at least communicate to me that the level of security is at most 256 bits. And removing all dependencies on rand would make it obvious where the entropy must be coming from (the seed parameter). Cloudflare's CIRCL[0] library does a bit better, but shares some of the same problems.

[0] https://github.com/cloudflare/circl

I don't think the consensus is really necessary. Right now we live in a world where version control and patch management is still pretty high cost. That leads to fewer active forks of each open source project.

As the technology improves, I expect us to move to a world where each project is actually a cloud of forks. So instead of rebranding every time there's a fork of XYZ software, we just refer to the forks by the name of the maintainer. e.g. I use Chad McProgrammer's XYZ.

It seems like some people want unity and sameness for its own sake, or to enforce their vision of a project on the users. I just want the software to work as close to my ideal as possible, and am willing to shop around maintainers to find the one that I personally consider the best. Why would you compromise if you don't have to?

Comparing software projects to governments usually produces the wrong intuition. The stakes are much lower, and risk tolerance should be much higher with a software project. Dictators are good, forks are good, even conflict can be good because it means people care. On the contrary, democracy leads to mediocre decisions, designs by committee, and sluggishness.

Unlike with a government, you can easily walk a way from a software project or create a fork. There is almost zero friction to "voting with your feet" in software and it works.

It's always been CYA. They know people are using it for this, and they want to keep answering these sorts of queries. The changes just reflect the latest guidance from their legal team, not a change in strategy.

Modern LLMs are already better than the median doctor diagnostically. Maybe not in certain specialties, but compared to a primary care physician available to the average person, I'd take the LLM any day.

These things go slowly an then all at once. The catalyst will be one or a few of the AAA November titles shipping with Linux support. That will eliminate most of the gaming crowd's last reason to cling to Microsoft.

It may even kill console gaming because the Steam Deck is already a fantastic experience just waiting for more games. It's not a small demographic either, it's something like 40% of males age 18-35, plus all of the people in their circles who come to them for tech support. Once market share gets up to 30% or so it becomes a cool trend, that other gamers want to emulate, streamers and influencers get involved. Then around 50% market share the bullying starts. "Windows is for people too stupid to figure out Linux" says a Linux Mint enjoyer to a Windows 11 plebian.

Valve has done a great job getting things started, but it's the studios' turn to make a move now.

For projects without funding, there is typically a trade off between a polished coherent product, which means saying no a lot, and a bloated product that has enough maintainer bandwidth to stay around. The second means saying yes to things which may not make the product better, in order for newcomers to feel bought into the project and want to maintain it.

For something like an editor, where whole features can be turned off by default, there's quite a bit of leeway to add bloat and get newcomers to buy in, without actually making the product worse.

For a programming language, a feature in the language has to be used by everyone. So the leadership has to say no a lot to keep the language high quality, and that makes it hard to get newcomers to buy in.

Unfortunately you can't have it both ways without paying people to maintain the project. Elm was good because the leadership said no...often. It's dead because the leadership said no so often that no one wanted to help maintain it. No one is going to waste their free time working on a project that won't accept their ideas, nor should they.

A language like Go doesn't have this trade off. If the Go leadership rejects a google employee's proposed language change, the employee still has to do maintenance chores as directed to keep their job.

Being able to build high quality software alone is a distinct skill from being able to make a group of engineers productive. Neither are soft skills, it comes down to how the software is architected and how well you can produce, understand, and communicate designs with the other collaborators.

I do consider helix to be an impressive piece of software, and I agree that the user base is growing, not necessarily the set of effective maintainers though. The maintainers don't seem to have any aptitude for coordinating engineering effort. That would be fine, if they were honest and direct about it. SQLite is a project which does not accept contributions, I think helix should do the same.

Put differently, I don't expect the large community to have a meaningfully positive effect on the quality of the software, because the maintainers have not demonstrated the competency to effectively utilize that labor. I expect helix to continue slowly improving at whatever rate the maintainers can make important changes themselves.

> It's rarely a good idea to do a bunch of work on a big change to an open source project in a direction that has not been validated by the maintainers.

While this is good advice in general, it doesn't tell the whole story in the case of this specific project. The helix maintainers have a track record of giving very slow "no"s and wasting contributor time. They encourage contributors to fix various odds and ends, until the PR has been nit picked to death, and then finally the concept is rejected. Totally backwards, good project leadership would front-load the conceptual yay-or-nay before reviewing any actual code.

> but they can be… stubborn about what gets into the core.

Yes, as an onlooker who is similarly cautious about moving to helix, I consider this to be a major risk factor. I've watched the maintainers waste dozens of hours of contributors' time, and leave the project with no improvement afterwards. I would actively warn against anyone trying to contribute to the project. The maintainers simply don't know how to run an open source project, and it's unlikely you will be able to accomplish anything. It's fine for a project to not accept contributions, and if you don't have the skillset to leverage contributor labor, then it's better to be upfront about it.

That being said, I hope they figure out the plugin system, or someone forks the project to add the missing table stakes features.

> Spoken like a Linux software developer

These techniques are pretty general purpose. They aren't merely a cultural artifact of Linux or FOSS. Anyone trying to sanely deal with authorization is going to stumble upon sandboxing, and capabilities, and the principal of least authority, etc. if they look hard enough.

Polymarket is not even close to the same thing. Sports betting allows a blessed few corporations to run rigged markets and intentionally prevent price discovery by keeping the smart money out.

Polymarket uses open orderbooks where you match against someone else who wants the other side of the trade just like the stock market. Prices are set by the market, as they should be.

Yes, it is possible to anonymously aggregate votes from a set of public keys, and ensure that no key has voted twice. It's also possible to ensure that one's own vote was included in the total.

The fact that this is even possible is deeply un-intuitive as it requires some of the most sophisticated cryptography. That's probably the greatest barrier to adoption. When people think of electronic voting, they think about trusting a company to make machines that operate on plaintext, and require humans to guard access to the machines. They aren't thinking about systems that are provably correct, where it is more likely for an asteroid to wipe out the country conducting the election than for the election results to be incorrect.

For the details and tradeoffs, I highly recommend Vitalik's blog.

Yes, as long as the passports implement a signing scheme, and the set of valid public keys (the electorate) can be agreed upon. If you can sign arbitrary data, then you can sign other public keys, including whatever the voting system requires.

Vitalik has a great blog post about blockchain voting.

https://vitalik.eth.limo/general/2021/05/25/voting2.html

You probably wouldn't want to use the cryptography on the passports themselves to implement the voting system. You probably want to use one of the general purpose zkSTARKs or multi-party-computation systems.

But what about for state that the application doesn't really "own"? e.g. I want to open a PDF in an editor. The PDF is in my documents folder, and I don't want to expose all of my documents to the application in its sandbox.

Fine grained access to single files should be given out using a file picker. The application manager passes in a socket to the application sandbox. The application connects to that socket using a known hard-coded path. It sends a message (client->server) over the socket, the listening file picking process opens a new GUI window to prompt the user to select a file. The user picks a file and a file descriptor is sent over the socket to the application (server -> client).