I've set up myself once to learn Helix. First there was Kakoune that sounded exciting with its new modal model, but what had me wanting to really give Helix a go, beyond being exciting, was that it advertised itself "batteries included". It promised to deliver all the cool things programmers' editors do recently.
But then I stopped abruptly when realized Helix misses a key feature of Vim: swap files. I can just start editing and have not have to worry about losing my work, may whichever of computer panic, computer running off charge, environment (desktop env or tmux) crash, etc. occur.
So edit semantics is cool, but fundamentals like recovery should be got right before being a serious contender.
(I did a quick search to see if there is any news on this front, but what I found is all about "recovery hooks for panic", which is far more less than what's needed - it's about an emergency saving of the work if something goes awry with the editor. I need to be protected from loss if something goes awry with the environment too...)
Does anyone else use swap files? Personally, I find them annoying. Saving every time I leave insert mode is my preferred alternative: `autocmd! InsertLeave * silent! update`
Interesting how every use case is different. I personally hate swap files (they pollute directories and cause annoying warnings when opening the same file two times).
In my previous workplace I used to use Workflowy to keep my to-do list in. I had a script that generated OPML from data pulled from Bugzilla / GH Issues / Jira, which then I could paste into Workflowy and from that on, update it interactively in their web UI. The Workflowy data was daily synced to Dropbox (as OPML) which in turn was synced to my local machine, so I had all the data at hand in usable format even offline.
(OK, OPML is not utterly human friendly as such; actually when I needed to access it locally, I parsed it and used it in an interactive programming environment.)
The post says "Most of our Ruby code reads like English, but that’s not the case when we combine multiple DateTimeFns class methods", and to illustrate this, gives the following agreeably ugly example:
This is correct, and the customer has full rights to redistribute. But the original customer may be limited to paying Red Hat customers only and still remain in full compliance.
What? So far the consensus is "probably is compliant (minimally), but a good set of lawyers may be able to argue either way, depending on the jurisdiction"
As I understand it (not a lawyer!): When you have a business relation with Red Hat (agreed to their T&C) and you choose to use the GPL-ed sources outside of the T&C you agreed, Red Hat has the right to terminate this business relation. The GPL-ed Sources you got during that business relation are under the terms of the GPL and thus it is within your rights after the business relation is terminated to use those sources anyway you like within the terms of the GPL. If you don’t like this arrangement, do not use RHEL.
The GPL does not allow you to put further restrictions on the redistribution of sources. The termination of your business relationship can be argued to be a restriction. It's not settled.
> The termination of your business relationship can be argued to be a restriction.
It's not a very good argument. The GPL does not state nor does it imply a continuing duty to deliver you source code. You have a right to the source which corresponds to the binary you've been delivered. Period.
If I release a new binary to which I hold full copyright, after having delivered GPL sources to you, and I wish to change the license of that software to fully proprietary, your rights are not restricted re: the GPL bits you've previously received. Why? Because you should still have the source to the binary you received from me that was licensed as GPL.
This is mostly true, but there's nuance to that which I believe doesn't make Stream a "fully GPL compliant target for RHEL sources".
Some sources do not hit Stream in a way that makes it possible to rebuild a release of RHEL verbatim, and devs can and have reported issues with compiling against Stream for deployment to RHEL, especially for the latest versions, where Stream and RHEL are diverged for a time.
the fuss is when this whole arrangement goes to an outside party for contract: companies that indemnify their partners; that have compliance requirements by law; that sign contracts to provide service that have strict clauses, all need the commitment of strong contracts with their OS supplier. Those kinds of customers are exactly RHEL customers, in many cases.
I really think this is all due to the Rocky/NASA deal. Their sales team (IBM/RH) must have freaked out. If Rocky can put a deal like that together then so can Oracle.
I felt bad for Mike McGrath when I read his apologetics. The technical guy playing as a pawn in a proxy battle between salespeople and lawyers.