111–120 of 245 posts
I used to use kitty, but its CPU usage was on the higher side on my laptop. I tried alacritty but the lack of tabs (after using kitty for a long time) was a deal-breaker. I'm currently using Wezterm[1], another rust-based terminal, which has tabs. It's worked great for me so far. 1. https://github.com/wez/wezterm
Do you need tabs still if you use tmux by default?
A PR is a gift and a burden. A gift of someone else's effort to contribute and push something forward. A burden because once received, future maintainance of the gift is really on the one who received the gift. It may as well be the gift of a kitten... you now have to look after the kitten for the next 12-15 years. Is it socialised? House-trained? How much effort does this take when there are also gifts of other anim…
Rejecting a gift is quite a rude gesture. Rejection a PR contribution until it receives further iteration after some thoughtful feedback is anything but a rude gesture.
I think this mindset that open source maintainers are obligated to accept PRs as gifts is the source of much of this frustration. The PR should be a starting point for further discussion, iteration, and collaboration, not a one-way gift that places a burden on the maintainer to satisfy the wants of the contributor.
Earlier quoted context omitted.
I don't know about you, but I think I'm capable of polite conversation with someone whom I believe to be talking nonsense; or being friendly in discussing something I think is no good. (In fact, maybe I'm willing to offer an example.. :/ - https://github.com/posquit0/Awesome-CV/pull/372#pullrequestr... - could have been better perhaps, but I don't think it's too off-putting if the author has a legitimate change they…
> The fact is that most programmers do not have the patience, skill or experience to write half-decent code that isn't bug-ridden garbage. It's not about PRs. Read it carefully. It's a comment about 'most programmers' who apparently don't have characteristics that mean they can do anything but produce 'bug ridden garbage'.
> The barrier to entry isn't mailing lists, or Torvalds, or perfectionism or gatekeeping.
i.e. the context is reviewing (however that's done) contributed code.
> Let's look at another project, alacritty. Don't we all remember it? It was supposed to bring Rust to the mainstream Linux desktop. It was supposed to be the new standard tty. It was supposed to be a revolution, shaking the foundations of the Earth No, it was just supposed to be one of the many projects with ambitious goals, that more often than not, go nowhere, and are abandoned a few years down the line... If you'…
What makes for a project's success then?
Is it the leadership? The raw motivation?
How do you facilitate interest?
Where are the developers and productive users coming together to talk?
I ask because I don't know how long I've really been on "the scene" myself and I do truly still feel there's something special about projects like Alacritty and Rust. When I look around and compare tools, mostly, I see nothing but the same song and dance.
The issue with many open-source projects is that most maintainers are of the philosophy of "let's ship it, we can improve it later" for their own code, while they expect incoming PRs to be perfect, to handle all corner cases, past and future, or else they'll be stuck in limbo, unanswered or picked apart over months, one line at a time, until they ask for a perfect implementation which requires 10x the time investment…
The main challenge in open-source is communication.
I think many developers treat PRs as an opportunity to gatekeep. I'm not a very politically correct or emotional person but I think gatekeeping/nitpicking is extremely demotivating and it should be avoided wherever possible. When I review PRs, I'm looking at the big picture. I'm looking to see if it introduces security issues or diverges from standard practice. I don't care if there's a slightly better way which redu…
An open-source maintainer should be gate-keeping the project.
Open source is great in that it enables many people to suggest improvements, but the PRs should be viewed as a proposal for collaboration.
Not all PRs are created equal. Far from it. They span a very wide range of quality. Letting every PR into the project will quickly accumulate a lot of technical debt and place even more burden on the maintainers to do further work to undo the backwards steps of the bad PRs.
When keeping quality high (or even just average), gatekeeping isn't inherently a bad thing.
Ha, trying to get Alacritty to have a native-feel icon for macOS which had basically zero drawbacks and most other applications do was met with a straight up NOPE. Not up for debate, people supplied the assets and I even made a PR, nope, closed. Even though it was in a directory full of platform specific stuff (Alacritty.app resources), it was decided that it couldn't differ from the other icons, so Alacritty has to…
I’m guessing this is about https://github.com/alacritty/alacritty/issues/3926.
I can well understand this being knocked back; as a non-user of macOS I would knock it back too. The main proposed option is frankly a fairly poor reimplementation of the logo and loses too much of the character of the original logo. A more conservative adjustment might stand a better chance. (chrisduerr also quibbles over the idea of maintaining different icon graphics for different platforms, but I suspect this may be more a further complaint about something that he’s otherwise already not happy with: that if the proposed icon was actually true to the Alacritty logo he wouldn’t object so much, though it’s still not an entirely unreasonable complaint—Apple are probably going to change their style in another year or two anyway.)
Admittedly the current icon isn’t great, because it’s taking the full width available to it, where native square icons look to go for 10% border on each side. I imagine you might have much more success just fixing the icon’s scaling (e.g. down to 90%—because it’s not square, 80% would probably be too far).
You could also try adjusting the aspect ratio just a bit, slightly squarer, but leaving everything else the same—that’d be about as conservative as you could get while still varying it for macOS. That’d make it a fair test of the idea whether chrisduerr is actively against having different source icons for different platforms.
Earlier quoted context omitted.
Isn't that up to the maintainer? A maintainer might not want anybody else working on the code with them even. FOSS license != community project.
Yes of course, that's their decision. What I'm talking about that you can't expect the same contributors to a critical part of infrastructure as to a, well, more or less useless terminal emulator. You can't do the 45327th copy of something (yes, yes, I get it, it's in Rust) and behave like your project is the Linux kernel or the Rust compiler.