spartanatreyu

joined 2 years ago
[–] spartanatreyu@programming.dev 8 points 1 day ago (2 children)

This is the kind of divorced from reality slop I expect to see from managers who think that 9 mothers can birth a child in one month

[–] spartanatreyu@programming.dev 9 points 1 day ago (4 children)

I don't understand comments like this

It’s a wishlist of Open tickets. Wouldn’t necessarily even call this a commitment to a roadmap.

Roadmaps are just wishlists with a committed to priority list, like an assembly line. Programming doesn't work like an assembly line and anyone trying to convince you to the contrary is ~~bullshiting~~ marketing.

Every task has the potential to bring forwards new information that changes the order in which tasks should be completed, let alone which tasks even need to attempted. You only get all the information once you've finished.

Instead of having an inflexible commitment, use a wishlist, and do the tasks in order of which one makes the most sense at the time.

75% of Open tickets will never get resolved anyway.

Based on what?

You can clearly see that practically all tickets in their previous epoch were resolved: https://github.com/orgs/pop-os/projects/23/insights?period=max

[–] spartanatreyu@programming.dev 3 points 3 days ago* (last edited 3 days ago) (4 children)

If I were a uutils developer, I would stay far away from all of these discussions because of how much hate is directed towards it.

I only see the hate towards this project being either from anti-rust trolls, or misdirected hate from Ubuntu towards switching to a new coreutils implementation on an LTS release before full compatibility has been achieved. I don't see any hate in regards to licensing.

If they do not adopt the license you prefer, would it be better for them to just go ahead and abandon the whole effort? Are there efforts really so valueless simply because they chose the license that they did?

Their efforts have value, but the value is limited by its current license. MIT licenced projects have a recurring history of being improved privately without those improvements going back into the project. It leads to a lot of duplicated, wasted effort. There may also be the potential for patent issues with the licence. No one wants to deal with some litigious asshole or company going after the project turning it radioactive.

Moreover, is dictating to volunteers what license they should be using for their code what you think this community should be about?

I think bringing up issues with the project is definitely something that should be brought up. As for dictating which particular licence is used, that's up to the contributors, but that doesn't mean others can't give their input. It's also likely that most of the contributors will want a license that allows the project to safely continue into the future.

You claim that it is important that people make tons noise in every single post on uutils because it will prevent a bad scenario down the line, but could you detail what that scenario is? Because people like to make allusions to such a scenario constantly but refuse to get specific and then engage on a discussion on the specifics.

I thought the Redis example was a good example of this.

I continue on this point further down, but I'm leaving this right now to stay on topic with redis.

Incidentally, your choice of Redis is an example exactly illustrates my point that this license is not a gigantic deal it shows that the worst case scenario is… uutils being forked.

The community was fractured. A report by an enterprise support company said 75% of existing redis users were motivated to seek alternatives. I'm not sure what number you would consider to be a gigantic deal, but Redis certainly thought it was, otherwise they would not have reverted back to the previous license.

Heck, it can even be forked at any time with a copyleft license precisely because its existing language is permissive.

It can be forked, but relicensing can mean needing permission from every contributor of the original, and/or removing all contributions from those who don't agree to the new licence. Not to mention the community fracturing, and legal issues. It's a massive effort that can be prevented by the original project choosing a better license earlier.

You claim that it is important that people make tons noise in every single post on uutils because it will prevent a bad scenario down the line, but could you detail what that scenario is? Because people like to make allusions to such a scenario constantly but refuse to get specific and then engage on a discussion on the specifics.

Well this comment is probably getting too long, so I'll simply point you towards the busybox licensing drama.

[–] spartanatreyu@programming.dev 9 points 3 days ago* (last edited 3 days ago) (6 children)

So it needs to be commented on in every single article?

Yes

If so, is that going to change anything?

Potentially.

The alternative is not bringing up the concern and it goes forgotten until it is too late and we are stuck with the results of bad decisions for no good reason.

Developers voicing their concerns is the only way things can change for the better.

Here's two examples:

  1. Redis licensing rug pull

    • Redis unexpectly changed its own licencing
    • Developers demanded Redis return to its original (or similar) licence
    • Redis said no
    • Developers formed their own Redis clones from scratch with compatible APIs
    • Developers switched to the new Redis replacements
    • Redis returned back to the original licence in an attempt to keep existing users
  2. Google's JpegXL whiplash

    • Google added support for jpegxl in Chrome
    • Google removed support for jpegxl in Chrome in favour of inferior standards
    • Developers demanded support added back
    • Google said no
    • Developers flooded every issue tracker and feature request with support for jpegxl, consistently, unrelentingly, for years
    • Other browsers add support for jpegxl
    • Creative industry adds support for jpegxl
    • PDF association adds support for jpegxl
    • Google forced choose between jpegxl or fall out of supporting pdf standard
    • Google readds jpegxl support

And there's plenty of other examples (e.g. Microsoft against linux -> WSL support, etc...)

If developers don't voice their concerns, then things stop changing for the better.

[–] spartanatreyu@programming.dev 16 points 3 days ago (8 children)

Licencing is a legitimate concern (not noise), even more so considering it's for the core utils

macOS has far better desktop applications across the board than Linux. What you get for free with a Mac is nothing to sneeze at:

Counterpoint: The apple of yore is not the apple of today.

Recent examples:

At this point, the beginner-friendly linux distros (Linux Mint, Ubuntu, Kubuntu, Bazzite) are more sensible and logically consistent than either Windows or MacOS.


Tangent: If you're looking at paid git clients on MacOS, I'd recommend fork over Git Tower or Kaleidoscope.

Significant whitespace, minimal ceremony

Well that's an oxymoron. If you're having to alter the whitespace instead of the code because the whitespace is significant than all you have is ceremony.

[–] spartanatreyu@programming.dev 1 points 3 days ago* (last edited 3 days ago)

Not if the standards rely on dedicated hardware, for example: security enclaves.

The whole point of using a security enclave on different hardware is so that its memory cannot be accessed or polluted by a process or side channel attack on the main hardware.

Counterpoint: Public funds pay for software used by military and intelligence services. Certain information becoming publicly available can lead to real harm. (e.g. A self-assessment on a country's own weaknesses, methods that spies deployed abroad can deliver information back, etc...) How do you manage the infohazard risk?

all software paid for by public funds should be open source.

Should probably be changed to: all software paid for by public funds should be open source so long as their is no or low foreseeable infohazard risk.

[–] spartanatreyu@programming.dev 1 points 1 week ago (2 children)

Counterpoint: A government portal needs to be extremely backwards compatible to support as many people as possible. That includes supporting devices that don't support the latest standards.

That should be:

People ~~use~~ used windows because it ~~has~~ had decades of backwards compatibility sort of.

Nowadays: it has current compatibility sort of.

Microsoft is a mess now, so it's no surprise that their current Windows version is also a mess.

Can we give it ears instead so it'll hear us when we tell it to fuck off?

 

Feel free to tweak the two custom properties in the css pane to explore the different mosaic patterns that are generated.

16
I made a thing (codepen.io)
submitted 2 years ago* (last edited 2 years ago) by spartanatreyu@programming.dev to c/webdev@programming.dev
 

Single HTML element + CSS only

  1. Inhale for 4 seconds
  2. Hold for 4 seconds
  3. Exhale for 4 seconds
  4. Hold for 4 seconds

And repeat

Inspired by: https://quietkit.com/box-breathing/

Note: The current Safari version has a bugged linear() implementation that has been fixed in the upcoming version.

 
 

Shows a great example of JS' new using keyword (similar to defer in D, Go, Swift, etc...)

 

Comments should provide context, not repeat what the code already says. The Redis codebase has 9 distinct types of comments (Function, Design, Why, Teacher, Checklist, Guide, Trivial, Debt, Backup), each with a specific goal in mind.

view more: next ›