Some further thoughts and a more positive spin based on watching the (breathtakingly fast) what's new video...
Several of the features regarding merging, synchronisation, metadata handling are available now (not in the 'DOpus 12 light' release from 2017 I was using).
I will gladly pay my money for the pro version and look forward to using the latest version with my own cat videos.
(Still consider the features as too configurable and not easily 'discoverable' particularly for 'normal' rather than 'tech' users)
I also recognise how amazingly talented the small DOpus12 team are. They've implemented something that Microsoft should have done....
e.g. those of attribute changer https://www.petges.lu/ modifies metadata between source and destination without changing the underlying identical files.
e.g. personally find winmerge and winscp a simpler solution to some aspects of comparison and synchronisation (but need setup)
Overall I do use Opus regularly but largely to just get a count of the contents of a directory (avoiding a manual file propperties right click on the folder.)
I appreciate the software development costs, but £25 for a single node locked license is steep. I'd like to see that extended to at least a couple of PCs + a laptop as many advanced users (who can regex :) ) are likely to have at least a couple of PCs round the house in these work from home days.
Overall 3.5 out of five - undeniably powerful but interface is too fussy
An extension of the zig ideas is making self contained portable and very small binaries that run everywhere from bare metal to any OS using a cross platform libc and configuring GCC or clang appropriately.
As noted below, my initial wording was unhelpful and misplaced.
The infrastructure costs are covered by sponsors. The 'They should monetise' was a 'they' that I now understand are external organisations rather than nixos themselves.
I'm really impressed with it and am ONLY seeking clarity. I'll be extremely happy if I can use it standalone.
Copyright, licensing are all I'm looking at.
e.g. Something like AGPL is considered copyleft and not compatible with 'open source' ethos. Still 'free' but the additional non-compete cloud service clause is both a sensible move, but something I'd just like to understand.
Your statement of 'what's wrong with people' is what is getting me. Borderline defensive. I'm definitely not knocking the product, quite the reverse. Its so good I want to embrace it wholeheartedly.
I have no problem paying for things, contributing voluntarily to a great product.
Its good to see that various organisations are committed to funding the infrastructure costs etc. (which negates my comment about storage servers).
It looks impressive but it isn't clear how much you have to pay for services from them. It isn't free and you aren't in control. Your snapshots and abilities to rollback etc are likely to be dependent on their storage servers.
They certainly should monetise, but not making it clear is what I object to. I've raised as an issue for clarification in their community wiki.
Ashley Broadley's github page at https://github.com/ls12styler sadly doesn't contain a repo with his rust dev work to date (I will ask him as it has some really good stuff in the article.)
----
Very nice. I'm doing similar at the moment. Maybe take a look at
To be truly portable it is worth considering whether your newly created Dev environment can work without the internet or in an air-gapped environment.
Vscode can be problematic in that respect. Typically with dependencies used by an extension often assuming they can reach out to other servers.
I look at initial internet facing container creation as a separately managed snapshot process to grab dependencies which then gets configured for particular Dev, build, test, runtime and release containers that are built by the dependency collecting original container.
Ie something like vscode isn't installed in the internet facing container, it is installed in the offline build of a Dev container. This is where the difficulties lay in my approach.
Cap'n'proto has a number of drawbacks both from the 'one man band' pov. (Witness the two year lull when Kenton went sandstorming), an awkward API and limited language support.
Personally I don't think there is a perfect protocol because different people want different things whether self describing, easy/optimised memory management, zero copy, partial decode. The list goes on....
At a pinch, flatbuffers with flexbuffer evolution would be close to my goals but I'd much prefer having a meta description of messages and perhaps access ,authentication, transport security and use that (e.g. an OpenAPI v3.1 spec) to generate an implementation whether in protobuf, msgpack, JSON, ASN1 etc. whichever is suitable for a use case and using an appropriate transport whether quic, TCP, UDP.
Some of the high performance work I've seen uses ASN.1 on a very large virtual server at 100Gb line rates because the messages lend themselves to parallel decode.
I think Mike Acton had it right by suggesting things are tailored to the data needs and not overgeneralised.
There is an alternate view of what microservices should be. Check out the sample chapter for Monolith to microservice by Sam Newman.
As described in this article, microservices seem like just a way to horizontally scale development and deployed implementations. Nothing like independently deployable network functions corresponding to business needs.
Several of the features regarding merging, synchronisation, metadata handling are available now (not in the 'DOpus 12 light' release from 2017 I was using).
I will gladly pay my money for the pro version and look forward to using the latest version with my own cat videos.
(Still consider the features as too configurable and not easily 'discoverable' particularly for 'normal' rather than 'tech' users)
I also recognise how amazingly talented the small DOpus12 team are. They've implemented something that Microsoft should have done....