Certificate transparency doesn't prevent misissuance, it only makes detection easier after the fact. Someone still needs to be monitoring CT and revoke the cert. I actually believe most HTTP stacks on Android don't even check cert revocations by default.
I'm not too sure what the detection process is like, but being found to sign fraudulent certificates results in your CA being untrusted and is the end of your business. So it's not going to be done lightly even if there isn't automated systems to catch it instantly (which there likely are at least for major websites)
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.
That's a relatively recent development. Repairability has been very poor for quite a while, but now they're finally starting to improve the situation somewhat.
You can (partially) blame Microsoft for that. I still don't understand why it's seemingly OK for device manufacturers to distribute such crapware through Windows update. New keyboard? Oops, spyware. Printer on your LAN? Here, let me install these 16 utilities for you. Just give me a driver without any GUI tools. Or at the very least prompt me before installation.
Oh I'm getting so tired of this. Lately there appears to have been an uptick in this kind of marketing spam too, there's so many companies trying to advertise their AI products this way. At least it's a good indicator of which companies I should avoid at all costs, and it provides me with an email address I can use to direct my angry emotions towards.
They're getting more aggressive at it too. Just yesterday I received an email from Alignerr (not YC affiliated I think) saying that my sign-up was complete and cheerfully welcoming me to their platform. I had never even heard of them. An automated "job opportunity!" email didn't arrive until 3 hours later, but by then I had already directed some angry words towards their support email.
Other, even less respectable projects are also regularly enrolling my GitHub projects into their platforms, and I have to actively reach out to them to remove it.
I'm so tired of this man. Can someone go and take away these organizations' ability to send emails?
One big issue with FPGAs is how annoying it is to learn how to use them. I did a course on embedded systems a few years ago and nobody could truly get to enjoy it because we spent most of our time downloading and installing huge toolchains, waiting for synthesis and PnR to complete and debugging weird IDE issues. We need to open up the space to allow people to develop better solutions than what these companies are forcing down our throats.
There already exist fantastic open source tools such as Yosys, Nextpnr, iverilog, OpenFPGALoader, ... that together implement most features that a typical hardware dev would want to use. But chip support is unfortunately limited, so fewer people are using these tools.
We decided to build a VSCode extension that wraps these open source tools (https://edacation.github.io for the interested) to combat this problem. Students are already using it during the course and are generally very positive about the experience. It's by no means a full IDE, but if you're just getting started with HDL it's great to get familiar with it. Instead of a mess of a toolchain that nobody truly knows how to use, you now get a few buttons to visualize and (soon) program onto an FPGA.
There's also Lushay Code for the slightly more advanced users. But we need more of these initiatives to really get the ball rolling and make an impact, so I'd highly recommend people to check out and contribute to projects like this.
The FPGA situation is the same as the microcontroller situation before Arduino blew open the flood gates: byzantine proprietary software and libraries you have to pay for to unlock hard IP functionality less you from scratch develop it yourself which can be very difficult. The Arduino gave people a solid kit: Simple to install IDE that wraps up a text editor, tool chain and libraries with matching plug and play hardware.
Arduino took microcontrollers from esoteric hardware for EE's to mainstream "makers" - people who were not technically educated but wanted to makes things using technology. FPGA's need a solid foundation like that.
I briefly worked with FPGAs and was having a lot of fun but the software really ruined it for me. I forget the details but I was moving my web license of the Xilinx tools to my desktop from my laptop, it kept failing and I gave up.
I'm all for your endeavor, but didn't see a device support list on your front page. Clicked the first of 2 links in your sidebar (docs) and got a 404. I'm not saying it's telling that your issues page works when your docs page doesn't, but it's not the foot I would have put forward.
Ha yeah, I agree the website isn't great. I set it up a while ago just so we have something to fill up the void. Right now it's just me and a professor of previously mentioned course who are actively involved in the project, so we've been mostly focused on the technical part.
That said, functionally speaking the extension is 90% of the way there. Synthesis, PnR, simulation, visualization and more all work for ECP5 & iCE40 FPGAs, and to limited extent some others as well. We have a few more features that we're working on, but a very solid basis already exists.
For technical reasons we have a bit of a deadline on finishing the project, which is likely in around ~6-7 months. So by then we intend to have a 1.0 release and very solid documentation out.
> it's just me and a professor of previously mentioned course who are actively involved in the project
Unfortunately, past experiences I have are that a very small academic team = stay away, project will have too many rough edges.
I hope your experience goes better. Tip: A revenue stream gives you something to work with. Failing that, carefully document your whole architecture so contributors will be willing to help.
## Irrelevant Complaining
Just ran across this last year: good looking software, great concept, first half of features work great … enough to hook me, so when I finally found out the other half was bug ridden I stuck it out but ouch. Needless to say, no design document so even fixing stuff was a pain point.
I know exactly what you mean and I share your frustrations with academic software. In our case I think it helps that our main goal is to provide a good user experience: we're not reinventing toolchains from scratch, but rather making existing ones available in a user-friendly way. Especially in the past year or so I've spent a lot of effort on reducing tech debt, modernizing the underlying architecture and squashing bugs. We've gone through several UI iterations just to see what would be most intuitive. Compare that to most pieces of academic software that should technically work, but are so difficult to use that nobody except the developers really know how to utilize it.
Our intention has never been to build a full alternative to e.g. Quartus Prime or Vivado that suits everyone's needs. Our main intention is to show people that FPGA toolchains don't have to be so difficult to get started with, and that alternatives are possible. And yes, I agree, that absolutely means good documentation on several levels to allow other people to continue working on the project. Good thing that's part of our mission, so it will be done; just takes a little bit of time ;)
Modern large productivity software (including IDE) are often "fragile".
Sometimes some configuration is wrong and it behave wrongly but you don't know which configuration.
Sometimes it relies on another software installed on system and if you installed the incompatible version it malfunctions without telling you incompatibility.
Compiling RTL to run on an FPGA is way more complicated than compiling code to run on a CPU. Typically it has to meet timing, which requires detailed knowledge of logic placement. I'm not saying that's impossible, just that it's more complicated.
So yes, in that sense I'm talking out of my ass. But perhaps you can help enlighten me what it is that makes building FPGA firmware different from building MCU firmware.
I just remembered I have a Xilinx I bought over a decade ago lying around somewhere. I don't remember ever plugging it in, but I do both the excitement of getting it and trying to figure out the toolchain and getting confused.
I agree but I think that writing yet another IDE extension is not going to solve the problems. An IDE will bring you one step further away from the actual hardware, and makes it more difficult to solve unexpected problems. Also, not everybody likes IDEs, some just prefer Vim and the commandline. An IDE is not the magical solution here.
Instead of focusing on the IDE, maybe focus on a build system. Look at how PlatformIO does it.
I agree, this won't be for everyone. But if you're trying to learn how to use FPGAs, I think it helps a lot to have a tool like the one we're building. The learning process is also inherently very visual: it helps a lot to see what the individual steps look like, how Yosys synthesizes your Verilog code, where Nextpnr places the elements, what the chip looks like, what exactly your testbench is doing...
People who want to stick to the command line can always just use the tools directly. The extension tries to stay close to the tools by allowing users to directly modify the command line arguments and making invocations visible to the user. Heck, you could even use our standalone 'edacation' tool to run tasks defined in project config files (although admittedly I haven't tested that in a long time, so it might not really work that well)
Our intention has never been to build a one-size-fits-all solution. We want to show people that these fantastic OSS tools exist and can provide a viable alternative to Big FPGA's tools. We hope to be(come) a source of inspiration for what the scene could look like if we just let go of these massive toolchains that nobody really likes to use.
Yes! YoWASP is fantastic. In fact, that extension came to be after we contracted the dev to create NPM packages for the WebAssembly bundles they're maintaining. We use the exact same bundles if the extension detects that it is running in a browser (or if the user explicitly wants to use them). However, if possible we prefer to download and maintain native tool bundles for performance reasons.
Their VSCode extension is a lot more basic than ours, but it might be more suitable for advanced users. It's basically just a wasm tool runner that you pass command line options into, whereas we also include things such as project management and various visualization options. Which one to use depends on what your needs are, really.
Oh christ, absolutely this. We spent some time evaluating FPGA for our purposes and ended up GPU instead (algorithms we running can be adapted to strength of either).
The concepts are easy enough but learning the toolsets are an exercise in frustration… the documentation/onboarding is either nonexistent or extremely unhelpful, and getting past the stage of “the entire thing doesn’t work because you misclicked a button in the gui several hours ago”. In theory everything can be scripted, usually in TCL, but this is also unstable and seems liable to break every different version of the toolsets.
Alongside Xilinx, we also looked at Altera/Intel OneAPI/dpcpp and this seemed promising until we realised we were encountering so many toolchain/actual compiler bugs that nobody else could have been actually using this, except the oneapi cloud platform that seemed it had been hotpatched to fix some of the issues. In the end, after selling us some compatible cards they dropped the OS and card from support. I guess this taught us not to trust Intel!
We decided teaching to Juniors would be an exercise in frustration unless hiring explicitly for, and decided to go the GPU route.
Open sourcing a piece of software, especially one that focuses on a broader audience like yours, can convince more people than just developers. The advantages of open source are well-known even among less techy people who aren't necessarily interested in self-hosting the application. It's a good way to quickly earn the trust of people who are initially sceptical of your product.
It shows to your potential users that, even if they decided not to trust the developer anymore in the future, they will likely still be able to use your application. Everyone praised Simple Mobile Tools until the developer sold it to an ad company. But because it was open source, people were able to fork the entire suite of apps to continue using them.
There's also a lot of growth potential. draw.io likely wouldn't be integrated into so many other products if it wasn't open source. It allows them to charge money (apparently) for specific integrations, simply because everyone is already familiar with the product.
Typst is another good example. Their compiler is free and open source, but the web app is not. Certain features of their web app require a subscription, which allows them to pay the bills. But I (and many other people) wouldn't be using and recommending it if the core wasn't open source, because if Typst ever disappears, I still want to be able to compile my documents. Currently this might not matter much for your app since PDF is a universal format anyway, but as you flesh out your product, it will become more important.
It's difficult to monetise open source software, but so much more rewarding if it does work out. And your app being targeted at the general public gives you a massive advantage, since the potential market is so much larger.
Actual Airtags rotate their keys on a daily basis (when in lost mode), and Apple can't predict those keys. Theoretically they could tell that you're looking for a tag reported by devices x y and z, but the actual locations are encrypted.
reply