I do not think so. The Windows - OS/2 war was a big fight that Microsoft won on merits. Windows 95 was revolutionary at the time, folks queued at the malls on the release day to get it, bugs and all.
They fought the compiler wars with real engineering, giving Borland a run for the money. Different people have different opinions about Visual Studio. As a Linux user since 0.9 I did not like its architecture and focus on GUI at the expense of everything else, but I still saw it as a consistent framework done by excellent engineers. And so on.
On the desktop, I don't believe Microsoft has had significant competition for quite some time, likely back to Windows 95. In the server space, NT fought really hard against the UNIX giants of the time.
I think you might be missing the ‘concerning’ part. Which specific cases are concerning? I don’t find it inherently concerning that people can’t escape justice by crossing the Hungarian border, Bonnie and Clyde style.
Too explicitly spell it out, op is saying here that if any one of the 27 countries in the EU decides you are breaking one of their laws, they can have 1 of the other 26 enforce an EIO.
EIOs are subject to a dual criminality requirement. So it’s not as if arbitrary Hungarian laws can be applied in France via EIOs. And of course, we all know this is not happening, which is why we get radio silence from the people who are ‘concerned’ about this whenever specifics are requested.
Annex D is a list of things that are crimes pretty much everywhere.
Not sure what to make of the claim that Hungary might theoretically be enforcing Hungarian law in France. It seems surprising that no-one has noticed any specific consequences of this that you can point to.
The EIO is mostly just a formalization and standardization of a bunch of ad-hoc processes that were already in place. Law enforcement agencies in different European countries do try to assist each other, on the whole.
What you're missing is the erosion of the ability of the executing states to say things like "hey this is sketchy, we think this crime might not have happened", "hey the police department in this particular city is notoriously untrustworthy", or "hey this prosecutor is widely known in the local press to be corrupt and owns a collection of ferraris".
Now foreign authorities are trusted by default and significant parts of their reasoning are not subject to review, that's bad.
You understand that these aren't typically public, right? There's not any particularly good mechanism to discover abuse in this system in the first place, because the checks and balances are largely left to the requesting state.
>Where are search warrants issued via public proceedings? You could make the same point about any jurisdiction.
It's different though, typically you can fight those warrants after the fact, with EIOs you have to do the fighting in a jurisdiction you don't live in.
This is all deeply problematic because things like "probable cause" have very different meanings in different EU countries, even if on paper it's all supposed to be the same.
>Also, account first created in 2021, coincidentally starts posting right after the other account in this thread is replaced with a green account?
Maybe stick to one account? It’s confusing for the rest of us, if nothing else.
You are determined not to point to any specific examples and you keep switching to different abstract arguments. For example, you’ve now dropped the point about EIOs being non-public in some sort of allegedly sinister way, and are raising a different set of equally irrelevant abstract points.
>you’ve now dropped the point about EIOs being non-public in some sort of allegedly sinister way
Nonsense, I told you that EIOs are non-public after you repeatedly insisted on examples of them being abused. I did not suggest that there's anything sinister about them being non-public. The sinister part is outsourcing warrants to other countries. I can't trust that the French legal system will protect me in France anymore because now I also have to trust the Hungarian legal system, that's bad.
Frankly, it seems silly to debate about whether or not these systems are being abused when we know that Poland has historically issued one third of all EAWs.
Oh no, that's totally up to you. If you're happy with the courts in your country not being able to review the requests sent from Hungary, that's cool. Without transparent judicial review, how could we even know if the cases are concerning?
"Subject to review" means little more than "is the form filled correctly?", it certainly does not mean second-guessing by the courts in the executing state.
Like, yeah, your EIO will be rejected if you don't tick any of the crime-category boxes in the form.
I've never really understood how version pinning is meant to work with devenv.sh or Nix more generally. If I whack a .tool-versions file in my repo, everyone who works on it can use install the exact same versions of the relevant tools using asdf. That's low tech and imperfect (and certainly not a replacement for all of Nix's features), but it works as far as it goes. None of the examples on the devenv.sh page demonstrate pinning of tools/packages to specific versions.
As best I can tell, Nix enthusiasts think that this is an XY problem and that I shouldn't want to pin individual tools/packages to arbitrary versions. But the thing is that I am a rude barbarian who very much does want to do this, however philosophically misguided it might be.
If you use the flake system (which is technically still experimental, but everyone is already using it anyway), all your flake 'inputs' are automatically pinned in a flake.lock file that can be committed to git for reproducibility. So if you add nixpkgs as a flake input, your nix expressions will always be referring to the same exact package versions until you update the lock file.
The downside is that flake inputs refer to other flakes, not individual packages, so if you update the nixpkgs input it will upgrade all of your packages at once. For some packages such as Python, nixpkgs tracks multiple major versions so you can loosely pin to that version. You can also include nixpkgs as an input multiple times under different git tags/commits and only use that input for some of your packages to effectively pin them. You could keep using one nixpkgs but override the package's source to build it for a specific version/commit, but this setup could break in the future, because the derivation (and therefore build instructions) will keep evolving while your package's version will not. Or, if you really wanted to, you could straight up just copy the derivation from nixpkgs into your local repository and use that instead.
Nix is quite flexible so there's more options than just these, it just takes a little getting used to to find out what's possible. I don't use devenv myself, but some quick googling reveals it works just fine with flakes, so I would try that to see if it suits your needs.
If you care about the _exact version you are pinning_ (even though you will guarantee the pin between team members without needing to do this step), you can either pin nixpkgs repo to the state that had that version, source the target version directly, or for some ecosystems (eg ruby) you can just specify a version with a number and it has tooling to resolve that using "traditional" approaches.
In general though when working on a team, you dont really care about the _exact semver version_, you care about the major and handle version bumps by bumping the pin of nix packages.
It does, but its implicit (and so may not be the exact patch version you have in mind). See my other comment for how to handle if you _do actually care_ about pinning to a specific version explicitly.
Doesn't that pin me to a particular versions of nixpkgs? That's fine if I only care about nodejs, but if I want to maintain particular versions of different tools, it won't work.
Again, generally in other systems the full semver pinning is more of a crutch to get some 'reproducibility' that nix gives you out of the box at a much higher level. So, in general, people just pin to the major version in nix. But if you _really_ want the full semver pinning there are multiple options that I lay out in the other post. You can even patch the _actual nodejs source itself_ in reproducible/version-pinned ways.
I do want exact version pinning of individual packages. (As I said in my initial post, I’m aware that Nix advocates think that I shouldn’t want this.)
I’m not sure what other post you’re referring to. There’s one where you describe some approaches in broad terms, but as far as what the relevant devenv.sh config would look like, I’m none the wiser.
You still are pinning to exact versions of packages (and in fact are pinning to specific shas / content hashes of the packages) but you are doing so implicitly by going this "path of least resistance". The only thing that will change what _exact sha_ you are pointed at is an explicit update by someone. There is no risk of someone running install on one box and someone running it on another and them getting different _exact versions_ (or likewise, in CI it also will be the exact same). And in general thats what people are trying to achieve on teams by pinning to full semver. So thats what I mean by its generally not needed on nix.
However, to actually address your question it would be something like this (with ruby also added for comparison of whats possible depending on the language ecosystem you are using)
Pinning by version number isn’t a crutch; it’s more a question of mental models. Most people find it more intuitive to identify a world by describing the things in it than to fix the states of the things by identifying the world where they have those states. Nix sometimes feels as if someone read Kripke and missed the passage about possible worlds being a figure of speech.
In other words, many of us don’t think that version numbers are a crutch to be used in the absence of a totalizing hash of the entire state of the universe. We actually think that version numbers are, for many practical purposes, better than that.
I dont mean to imply its a crutch. Im merely pointing out that even though people say they want to "pin to a specific version", there are usually two different motivations:
- one group of people who want guarantees that what they install on their machine matches on their colleague/CI/prod machines. For this group, the nix happy path basically serves all their needs really well. It can capture nearly any sort of software dependency they have regardless of ecosystem and it pins to actual content hashes in most cases. They only care that the high level versioning is met, because again its reproducibility that they care about
- one group of people want guarantees of specific software versions. Nix still handles this, but its "more work" because nix is by default a snapshot of the entire world, of which your target software is only a slice of. And most nix snapshots of the world are "what were the most recent versions of each software package at this point in time". So you generally need to compose together multiple snapshots of the world. It works fine, its just more work (and more disk space).
In practice, again, I think most teams are served better by being in group one, but dipping into group two when they either need an "unreleased" version for software they depend on or when they need an older/unsupported version of software they depend on (or a nix release breaks their workflow). Then nix shines by being able to mix and match between different snapshots in composable/reproducible ways.
The way to do it is to find the `nixpkgs` version which contains the version of the tool you care about. There's a web site[1] that makes this pretty easy, and it's of course also doable by looking at the Git history for the program's derivation.
Then you create a named input using that nixpkgs version: either add it as a channel, import it with fetchTarball in a derivation, or add it as an input in your flake, depending on what you're doing. Then you use that named nixpkgs (or other input in the flake case) for that version of the package.
Edit: One issue with depending on things like git tags or semver versions is that sometimes people re-use versions or edit tags. Using the actual git commit hashes of the package's derivation avoids this potential ambiguity. This is why we can't have nice things.
Presumably the latter. However, mindlessly bumping package versions to fix bullshit security vulnerabilities is now industry standard practice. Once your client/company reaches a certain size, you will pretty much have to do it to satisfy the demands of some sort of security/compliance jarl.
This is cool and I had a little play around with it. The basic concept is integrating an AI agent interface inside KiCad.
I had some success with this prompt:
> Please design a simple, low cost amplifier circuit for the TEMD6200FX01 photodiode.
It's not news that LLMs can generate simple circuits, but what's useful about the integration is that the AI will iterate until KiCad's circuit 'linting' checks pass (which is a workflow that you can't trivially enable using a generic AI tool). On the other hand, the resulting schematic was so ugly I'd have rather just have made it myself.
Even leaving aside the unsavory views of the party you mention, it’s quite misleading (to readers who don’t follow UK politics) to suggest that there’s any hope of it winning an election.
> it’s quite misleading (to readers who don’t follow UK politics) to suggest that there’s any hope of it winning an election.
I wish.
Brexit was pretty unthinkable even just a few years before the referendum. And now… well, toss-up between the top 5(!) parties, because somehow the Greens and Lib Dems are polling at similar levels to Conservative and Labour, all a bit behind Reform who didn't exist a few years back.
And when bad times come, insular nationalism (both in the sense of xenophobia and autarky) poll well.
The world-wide bad-times storm is getting super-charged right now, though I can't tell how much this is malice vs. incompetence from the White House.
"an election" (what you wrote first time) != "the next election" (what you write now).
Next-but-one, perhaps. Although even for the next one, everyone's so weak I'd only put mild odds against them.
I don't want them to win ever*, but failing to plan is planning to fail, and there's big money getting involved here, and the UK political system still hasn't caught up with the impact of social networks and foreign influence through them at all.
And one of those social networks is run by someone who sees no problem calling for civil war in the UK, though he's currently supporting one of the other "I wish it was a joke party" parties.
* Although I can also say that about Reform, where, if I still lived in the UK, if my options were them or the actual literal Monster Raving Loony Party, I'd pick the latter. Then again, that doesn't say much as I'd pick the Monster Raving Loony Party over the Conservatives, too.
I think it goes without saying that things can change unexpectedly in the longer run, but this party simply isn’t a factor in national politics at present.
This defeatist attitude causes the situation we’re in.
Voting against someone rather than for someone is a sure-fire way to get some of the worst politicians in power as possible, they only need to be marginally less bad than the other candidate after all.
Restore Britain is a populist joke btw. Greens might be my side of the fence but they’re also populist. Hard to get air time as a small party without some form of sweeping emotional appeals and “common sense” thinking, even if it’s internally inconsistent and very broad.
No, I live in Sweden where coalition governments are pretty common and people tend to vote for the party they agree with.
Same is true in the EU elections, since their system is more democratic than the UK one.
I’m intimately familiar with the shortcomings of the election system in the UK as I am British, but I’ve experienced other formulations and I can see that this line of thinking enables the abuse you claim to be dispelling by allowing it to continue..?
Ah, but if there’s no higher truth, then you also can’t say that it’s wrong to sabotage your employer because of an ethical disagreement (or rather, you can say it, but it’s just your personal opinion). By condemning this course of action, the OP presupposes some sort of objective ethical standard.
https://news.ycombinator.com/item?id=46885305 (second paragraph)
reply