let increment x = x + 1
let square x = x \* x
let to_string x = string_of_int x
let result = 5 |> increment |> square |> to_string
(\* result will be "36" \*)
Does anyone have a good sense of how many dev hours it would take to write something like Quake/Unreal from scratch today? Not a port, but a full rewrite with a custom engine
IBM owns Ansible, redserk is saying Terraform will go a similar route. Although I don't see what they mean by core being lower priority than paid. The paid features are all available for free via AWX, which is the open source upstream of the paid product AAP.
Red Hat's business model is "Hellware"--the open source versions are designed to be incredibly difficult to install/manage/upgrade or without any kind of stability that you're forced to pay for their versions.
Linux now has eBPF, which is essentially a VM running inside the Linux kernel. You can run your own programs on this little VM and extend the kernel to a staggering degree. Some clever folks have used this to build open source tracing tools that rival and even surpass Dtrace in some ways. Brendan Gregg, a Dtrace wizard and old colleague of some of the Oxide team back at Sun and Joyent, has some great resources on the subject
I dug into portage a bit and I think I see what you're saying. But the only way Portage can automatically load a dependency is if the ebuild specifies it. For example an ebuild can install dependencies in DEPEND or RDEPEND by checking what USE flags were passed ([1]). You can also have CFLAGs which modify compilation without installing any dependencies. So for example, in portage if I install vim with USE=python, and gnucash with USE=python, then they will both pull in python dependencies based on what was specified in the respective ebuilds (see [2] and [3]), which will probably install the same version of dev-python libs. But that's only because someone packaged vim and gnucash with a USE=python option and specified the required packages for that flag.
You can do the same thing in Nix (e.g. you can package software with a bunch of options and pull in required dependencies based on the options selected by the user), but you're right that Nix doesn't have a standardized API for doing this like Portage does. I think it would be a nice thing to have. Maybe it takes a lot of work for maintainers to pre-package every possible build option like they do in Gentoo. Instead, Nix focuses more on providing a unified interface (the Nix language) for end users to modify anything about any package. nixpkgs is also pretty flexible, allowing maintainers to use packaging approaches that aren't "standard practice", and those approaches are all exposed to the end user if they need to make changes. This usually means reading the Nix package source to see what's going on if you want to make changes to a given package. For example some packages like vim do provide a nice interface for users to choose pre-packaged build options [4], similar to USE in Portage. Since Nix is lazy-evaluated, you just have to reference the dependency in the code somewhere (search for ${python3} in the linked example), and then that dependency will only get installed if that bit of code gets executed (e.g. if the pythonSupport option gets passed).
I think that's a big part of what makes Nix a pain, the fact that end users can make almost any change they can think of to any attribute on the entire system. But that's also what makes it very powerful. Right now most people use overlays, as people described above. So you can modify the "buildInputs" attribute (the set of build-time dependencies), or the "buildPhase" to pass some different CMake flags, or any install phase you like, for any package in nixpkgs (see [5] for all bajillion phases). Nix flakes might make it easier to compose custom set of packages, but I'm not sure how yet.
Oh and one more random tangent - this whole time I've been talking about build dependencies in Nix as opposed to runtime dependencies. That's because runtime dependencies are loaded automatically based on whether they get referenced in the final output of the build. Since every package has a unique hash, Nix literally greps the final build for package hashes, and if it finds any it loads them in as runtime dependencies. This is different from something like Portage where runtime dependencies are explicitly specified in RDEPEND.
Nix can be a huge pain to use, and with the recent redesign it somehow feels even more disjointed than before. But it's still one of my favorite pieces of software. I think a clean interface like https://devenv.sh/ could make all the difference (havent tried it yet but looks promising).
That said, if I understand you correctly, I think nix does let you do what you're describing. You can make an overlay, which is a way to modify a set of packages by reaching in and changing build instructions or add packages to the set. So, you can make an overlay of nixpkgs and add a modified libgcc called mylibgcc to the set. In the same overlay, you can modify package A and package B that depend on libgcc, and change their build instructions, including making them use mylibgcc as a build dependency. If you do this for then both packages will use mylibgcc as a single shared dependency without duplicating it.
Im on mobile but could try to send a working example if you need one, lmk.
This is wild speculation but just to highlight how FTP could be leveraged to get a signed DLL. Imagine SolarWinds has a "sign everything in this directory" script. Attackers gain access to that trusted directory either directly via FTP or by pivoting off FTP access. They just plop their DLL in there and let SolarWinds auto-sign it. No cert required.
I implemented an HSM-based signing service for a firmware attestation system a few years ago. Authorization to sign and an audit trail of signature requests were a big deal. Something like the "plop a file in a directory" would make me weep.
iMessage is E2EE (according to Apple). But Apple can still see who's messaging who. With that you get an intimate social graph. Similar to what the NSA has on US citizens via phone records. Apple also says they don't sell your personal info to advertisers. But they can still use that data however they like, and there's nothing stopping them from selling that data at some point in the future.
Why would they want to sell it. They could license access to it for recurring revenue, like other Big Tech companies.
The most important control that customers should seek is not control over the sale/transfer of data, it is control over how the data may be used, by anyone. For example, if the data comes with terms that say it cannot be used for advertising purposes, then what are the chances anyone can sell it to advertisers.
The "We do not/will not sell your data" line is a deliberate red herring, of no more value than "We take security very seriously".
Ocaml example: