Hacker Newsnew | past | comments | ask | show | jobs | submit | dzsekijo's commentslogin


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`

Perhaps helix has something similar?


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).


I don't fully get the story. Was it Calanacis who ditched the Econ reporter? He is the one among the All-iners who voted Harris. See https://audioboom.com/posts/8589911-bonus-episode-with-jason...


Yeah. But I think the goal was here to sugar the syntax while keeping semantics intact.


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.)

This was a nice hybrid workflow.


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:

  DateTimeFns.add_minutes(DateTimeFns.add_hours(DateTime.current, 1), 1)
Sure thing, but the syntax can be improved without restorting to refactor into instance methods:

  DateTime.current.then {
   DateTimeFns.add_hours(_1, 1)
  }.then {
    DateTimeFns.add_minutes(_1, 1)
  }


However, these days AI assisted tools can be involved in the task.


That's true but you must give the source to your customer and they should be free to redistribute.


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.


And they are! However Red Hat is then free to terminate their business relation with you.


Well, but then Red Hat's T&C may be a violation of GPL.

Red Hat bases its model on dwelling in the grey zone.

So if Rocky aspires to be a Red Hat clone... they can adopt this bit, too :)


Red Hat’s T&C is not a violation of the GPL. That argument is done and dusted.


Software Freedom Conservancy lawyers apparently are skeptical: https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis...


Skeptical, but not skeptical enough to sue to seek an injunction? They have standing, they have full copyright ownership of many packages in RHEL.


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.


Also, I don’t understand what all the fuss is about. The sources are available in CentOS Stream.


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.


That's not the consensus and "minimal" compliance is not a thing.


What stops then someone to buy a RHEL subscription for the purposes of setting up an unofficial RHEL source mirror?


They will terminate your contract if they can trace it back to you. Their ToS prohibit this.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: