No I don't believe it supports collaboration, though I could be wrong. This is really a pretty notepad with great Markdown integration, nothing much more (which is why it's still good!)
I've seen that previously on https://curiosity-driven.org/ (the main page is a feed file) but I'm not sure if XSLT support won't get deprecated and/or removed in browsers (since it's quite an old tech).
I guess the point is that XSLT 2.0+ is not shipped as part of browsers, nor is it expected to be in the future, considering the only implementation is (commercially licensed) Saxon, by the author of W3C's XSLT spec himself ;)
I can only hope this isn't the case, XSLT is a brilliant idea that's very underrated and a great tool to have in your toolbox.
I don't count how many times I've seen people attempting to create simple reports from some XML taken from some obscure back office and try to reinvent the wheel by doing some JSON conversion and process that from some other program that build up an html report
I wonder if that could be addressed at the spec level allowing reverse order of these keywords. It doesn't seem complex on the surface and the the engines could slowly add support for it.
This is probably in part explained by the sheer size of nixpkgs. It's the largest and freshest (i.e. with the most up-to-date versions) package repository among Linux package managers (see https://repology.org/repositories/statistics/total).
Unlike Arch it also is not a rolling release package repository and has both unstable and stable branches that it needs to maintain (along with different versions for each). In fact, the NixOS cache keeps every version of every package that has ever been built and stored in the cache so that binary versions of all historical package versions are available.
Finally it also includes packages for MacOS binaries as well as Linux ones.
I'm frankly surprised it actually costs as little as it does given that it's using pretty expensive S3 storage for everything.
the cache also stores the source code used to create the build. there’s been numerous cases where upstream code has been deleted on GitHub or elsewhere then rescued from nixcache.
What percentage of the total repo is source code? I would think the compiled artifacts could be tossed at a moment’s notice, but would not want to lose the source.
> C) provision certificates for this address using the DNS-Challenge approach rather than the HTTP-challenge approach.
The other "bonus" is that due to CT it leaks the internal name to basically everyone on the internet. It may or may not be a problem but definitely something to be aware of.
Unfortunately not. I wanted to produce PDF and epub versions in parallel with the HTML version, but getting those to be of sufficient quality would have blown the time budget for the project. There's some old code in the Git history for dumping the source to Pandoc's dialect of Markdown, from which I was going to generate those, but the differences in Markdown dialects are enough that it was a fair bit of work.
Dropping a print version and focusing on epub could very well be faster, as I suspect that an mdbook->epub pipeline is less challenging than creating a quality print-ready PDF. But no plans right now.
Having a tool that'd make it easy to run the app locally for development and at the same time have roughly the same files used in production. Docker compose got this mostly right, compare compose with the complexity of running locally service in micro Kubernetes cluster.
It would be very useful IMO to be able to easily move a service outside of Kubernetes.
The goal is to move the "fast loop" development outside of any container, onto the native system.
If I am not mistaken, all of the tools which help this either rebuild a container, or rebuild inside a container, right?
Given a Kubernetes application with service names, port forwards, etc., I would like to have an option to automatically convert these configurations into `ExternalName`, external port forwards, etc. This would be transparent to all services, inside and outside Kubernetes.
I think it can be done manually today. My colleagues at my last job wrote a helper script; credit to them for the idea. I think it could be built into `kubectl`. i.e. `kubectl apply --externalize serviceA`
Minikube is just one piece but it's not functionally equivalent to `docker compose run` since I'd still have to build and push docker images and edit k8s yamls manually (compose run will build containers and start them, no need to edit anything) .
Looks okay but I was looking for something that wouldn't require learning yet another config language and would rather take k8s yamls that I already have (or require minimal modifications).
> Define Sandboxes using a simple YAML file, specifying customizations relative to the baseline environment. Maintain these YAML files in your git repository and standardize Sandboxes across your organization.
It looks like these yaml files are not k8s files that I already have?
Also, is it open source? (I couldn't find a link to source on mobile)
Yes, these are our (thin) YAML files via which you describe the Sandboxes in terms of deltas from the baseline env. The K8s yaml files remain as the source of truth for your standard deployments. The operator is not open source. Some components like the CLI and Resource plugins are. We do have a free tier, however.
I'm currently reading "Stolen Focus: Why You Can't Pay Attention—and How to Think Deeply Again" by Johann Hari and there's an explicit mention of the negative effect on people that immediate notifications bring. Just wanted to mention that it's not only you.
Great to see some movement in this area for Rust. Compared to Zig which had this from day 1 it may be hard to adjust Rust (the way it was hard for Go to adopt generics).
I think most of the challenges are around making custom allocators safe without harming the ergonomics, which Zig hasn't solved.
If Rust was content to have use of custom allocators be unsafe it would be trivial to add them (since you could just add new variants of allocating methods that take an allocator as a parameter).
Are you just reminding us that Rust does some checks that Zig doesn't, or are you saying that there's some particular footgun in their allocators above and beyond the fact that UAF and other memory bugs are writeable in general?
Neither, I was disagreeing with the comparison to Go and generics.
Generics in Go don't add anything beyond what generics already do in other languages, so the challenge with bringing generics to Go is "how do we adapt the language to support a feature that already exists in other languages and is generally well understood". Bringing generics to a language that wasn't designed with them in mind has often resulted in a sub-optimal implementation (eg. Java vs C#).
On the other hand, "safe custom allocators" are not a feature that any language (to my knowledge) has solved. It's not as though this was an oversight in Rust's initial design: using a custom allocator in an unsafe context has always been possible in Rust, and it's too early to say whether bringing this feature into the language later will result in a similarly sub-optimal design: in order to be sub-optimal there would have to exist some better solution out there, and there currently doesn't.
Zig approach essentially parametrizes instances of containers on the instance of the allocator. To properly support that in the type system one needs dependent types.
In theory that can be done, but the consequences for the compilation time will be extreme as the compiler becomes essentially a generic theorem prover.
Plus the noise from the proofs in the sources will be much bigger than that of type parameters.
I’m pretty sure the ‘logic’ require for paramterizing container types over allocators can be restricted in a wide majority of cases to a linear set which would allow for refinement types to be used. This would eliminate the requirement for full theorem proving.
In fact, it would probably be acceptable to insist on keeping the scope of parameterization limited to the linearly determinable set of values and operations on those values.
Are you sure? I have no type theory experience but that sounds trivially expressible in Rust. The issues around making the stdlib allocactor-parametric have been about optimal api design, not theoretical possibility.
That just restricts A to implement Allocator trait and will allow to pass any instance of Allocator when calling methods of MyVect. This is unsafe. What is required for safety is to state that all methods of MyVec that receives the allocator reference can only work with one particular instance of Allocator.
To make this compile-time safe in Rust a typical approach is to embed the Allocator reference in MyVect and use regions to ensure that allocated data do not outlive the allocator. This bloats MyVect with a reference to the allocator. To workaround this one specializes for static allocators to eliminate the need to embed the reference to those in MyVect.
An alternative that is not covered in the article is to require that a reference to the allocator can always be deduced from the allocated data. This solves the bloating problem as the overhead can be reduced to a word per allocation page which is typically at least CPU page in size.
Still even with this the result is not optimal especially with arena-style allocators when one wants to ensure the max performance of tiny allocations.
> That just restricts A to implement Allocator trait and will allow to pass any instance of Allocator when calling methods of MyVect.
No, that kind of rust generic requires monomorphization rather than dynamic dispatch. Any given Vec must have a specific A, just like it must have a specific T.
> To make this compile-time safe in Rust a typical approach is to embed the Allocator reference in MyVect
Yeah, that was implied by the "...". It won't compile otherwise, generics have to be used (including by PhantomData).
But I understand the problem better now. You're right, there's no good way in the type system to specify "you must always provide the same instance of this allocator when calling any method on this vec". (I'm ignoring branding because I think it's not practically convenient).
I think realistically if you want to prove safety of memory provenance in zig, you assume that allocators are sound, and you just track the lifetime of the memory from alloc/create to free/destroy and call it a day. This is probably "good enough", and in rust you're assuming the allocation is sound as well, it's just implicit.
What you get for free with the global allocator is a guarantee that you will use the same allocator for each operation on an allocation. That is the property that is claimed to be difficult to keep if you literally do the Zig thing and have e.g. ArrayListUnmanaged which requires you to pass in the allocator again to free the backing slice.
Ok so those are 'unsafe'. Plenty of safe (when statically checked) data structures in zig, like the managed array list, where the associated allocator is attached to the object.
