_d7dt

I don't think that at all, I'm just another person giving my opinion, like you. Also, I don't understand why you said that, but then asked me to keep my opinions to myself.

I'm not sure where you heard any of that, but I have never heard any Red Hat employees say anything to that effect, ever. Fedora still exists, and to me that seems perfectly fine to install on a random laptop.

That blog is just one developer's opinion, not an official statement. Although I will say I share the opinion, Glade messes up my ui files and I can't recommend using it if you want to use any newer widgets. It has always had those problems, but now with GTK4 it's no longer really worth it to try to work around them.

Also, Glade is not really even used by GNOME designers that much, what they do is make mockups in some other tool (usually Inkscape) and then have the developers implement it. I don't know about other GTK based desktops, though I think some Elementary developers are working on this: https://github.com/akiraux/Akira

I've posted about this before, but if you want GTK and you believe API stability is the most important thing then you should just use GTK3. The API there is frozen. I'm not sure what "reputation" you're referring to but if GTK does not meet your needs, and Qt (or something else) does, then I think that's great for you, you should just use that.

What you've said is really not correct, at all. For one, Glade is not deprecated in the sense that it doesn't work any more, it still works okay with GTK3, however it has a number of limitations that may make it difficult to use (which it always had, nothing has changed here). Two, a replacement is being worked on, I'm really not sure what your criticism is besides "go faster" which, I'm sure we all wish we could write code faster and have it work perfectly and do everything the first time, but that's not realistic.

Edit: Just to be clear here, in my opinion the new tools will likely end up being a large improvement on Glade. Glade is a pretty old application that by design does a number of weird things that don't match current best practices, you can see some of them if you read the blog post that was posted above.

Please don't assume bad faith. Glade was not "killed," there are technical reasons why Glade cannot be used for GTK4 (I can give more detail if you want). There is currently a new tool being developed by a Glade maintainer, catch this guadec talk later this month if you want to know more: https://events.gnome.org/event/9/contributions/191/

Nobody is particularly happy about having to edit the XML directly but it's the best option right now until the new tools stabilize.

I'm not sure what you mean. It can still be operated offline, in which case there is no telemetry sent. The analytics is just another service that you can use.

Specifically, which legal threats and unethical behavior are you referring to?

This specific complaint seems to be about data privacy, not about a freedom being eroded.

Also, since you can fork it, as has been previously mentioned, there seems to be no purpose in objecting to this type of FOSS acquisition. Worst case, the project ends as it was before the acquisition, with no corporate support or funding whatsoever, at which point it seems it won't make any difference whether there was a complaint or not.

Generally, no, that's not what that law in the US is acknowledging. It doesn't make any special consideration for any definition of "spyware" or any other similar concept, it talks about all kinds of data collection, including ones that would be otherwise voluntary and beneficial for an adult. There might be some other US law that talks about that, but COPPA doesn't.

More exhausting than developing towards an entirely different (and often redundant) feature set without any help from upstream? That's what is usually meant by "fork." If you want the minimal effort option and you don't care about new features or security fixes at all, you can just stick with an old version, no fork is necessary there either.

I understand that you feel upset that they added something that you didn't want, but you don't have to continue adding to the division and cynicism. Forking is not the only move, and I would actually suggest against it -- what you want is simply a build with the telemetry disabled. I don't think you want to throw away any other new features that aren't related to the telemetry (and in fact, you may still be able to indirectly benefit from it that way if it leads to some valuable product insights from them). So characterizing this as greed seems to not make so much sense. If they were getting super rich off this and not making any other improvements then maybe you could say that, and I would join you in saying hey, something's not right here, but that doesn't seem to be the case.

I'm not sure what you mean, these laws aren't strictly concerning telemetry. Did you mean that telemetry is bad because children under 13 years old could accidentally use it? If so, that's the purpose of the law -- to prevent that. You can sue a company that is found to be unlawfully collecting data on children.

Please don't do this, this is needlessly divisive. You don't have to make these (incorrect) assumptions about me and what I will use.

I assume you have not read these type of privacy policies before, but it's extremely common for web sites and online services to disallow children under 13, at least in the US because of COPPA compliance. In general, it is illegal for commercial entities operating in the US to collect data on children under 13 (although in some cases there are some exceptions). See for example the Github privacy policy which includes a similar clause: https://docs.github.com/en/github/site-policy/github-privacy...

The issue here is that the server you downloaded the desktop app from is. You can reduce the amount of this you have to deal with by shipping a native app, but you can't get rid of it entirely as long as you plan to host a web site or a download of something, or if you plan to let users communicate useful things back to you (such as their hardware specs, OS version, crash reports, usage patterns, etc).

With that, I would say good luck troubleshooting your server if you don't collect any logs whatsoever. I wonder how you would even protect against bruteforcing and DDOS attacks if you never stored IP addresses for any amount of time.

I'm personally not confused, just disappointed. Sadly I've seen far too many FOSS discussions that become overrun with irrationally paranoid rhetoric, sometimes bordering on the reactionary. This stuff is nothing new. You'd think that with the ability to quickly check the code and recompile it to get rid of any unwanted bits, that would make this kind of attitude go away, but for whatever reason it only seems to make it worse.

Please make sure you check the privacy policy there as well: https://man.sr.ht/privacy.md

It's not clear what sort of thing you're referring to, it's generally not possible to make a service where you have accounts and billing, that simultaneously doesn't store your information. The whole point of it is that you want it to store your information.

>It's absurd to expect the word "community" to appear in the text of the GPL

I'm not sure why you're saying this? I don't expect that word to appear in the text.

It also seems mostly not possible to prove or disprove that "almost every person involved knew." Did you mean this as a personal anecdote with the people that you knew? If so, that's probably great for you and your community, but apparently those who were writing the legal document that governs said community didn't agree. Sadly it is possible for there to be oversights from day one.

Sure, but the "intent" in question would be the intent of the copyright holder that chose to use the GPL. My point is that the intent in a lot of cases is NOT to do what is being suggested.

I'm not sure what value you're suggesting rustc would be able to bring there. If you want that in LLVM you can try your luck with the "resurrected" C backend: https://github.com/JuliaComputingOSS/llvm-cbe

I don't understand why I see so many requests for LLVM-based languages to change around their backend or IR, that seems to be a huge amount of work for comparatively little benefit. The correct thing to do there is to just add support for those to LLVM.

I am familiar with the various other things that are hosted on the GNU website. I'm referring to the actual authoritative legal text that gets copied alongside all the source code that you use, not any other essays on the subject. That text poses a different story than those essays. I'm also not sure why this is being brought up now, as the GP post you made acknowledged that the GPL was not even accomplishing that goal.

Edit: Since the license itself is vague on what those "social issues" actually are aside from sharing and changing the program, in my experience projects will tend to use it for whatever they feel like. Sometimes this is aimed towards community building but often isn't. To me the community building aspect mostly happens outside of these legal decisions, for example: closed source programs can have a community too, sometimes that community might even be hosted in the same places such as github.

>when they allow private corporations to profit from the community’s work without recompense back to the community.

I'm not sure why this is frequently brought up in the context of the GPL. The GPL says nothing about that and has never held that as a concern at all. Communities who were using GPL with that intent have seemingly always been mistaken. From the text of the GPL: "the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program." It doesn't say anything about disallowing private corporations from profiting without recompense. If you want to force companies to pay you, you're better off with a closed source license.

If you want to use journald for those programs you could just configure them to pipe the logs there, or you could just disable journald logging and have it pipe its logs to the syslog. If your distro didn't configure all those programs to log to the same place, that's more of a distro configuration problem than a problem with any specific syslogger. I personally dislike having a bunch of services that try to implement their own log rotation, I would rather have that handled by the system.

I don't think it took me that long. I said this elsewhere but to me that is mostly a documentation problem, not anything to do with the underlying technology or the package format.

I don't install build-essential on a server, in a container, on a VM, etc. It really matters in those places. If you combine them then you lose the ability to deploy a small rootfs.

>his decisions seem to have worked out amazingly well.

As someone who regularly deals with bugs and inconsistencies in Linux, I wouldn't say so. For me personally, I just want to be able to fix the issues, and would rather not spend the time bickering with someone who has some kind of personal vendetta about something that I don't know about. I try hard not to dump my baggage on other open source maintainers, I hope others can do the same.

Hi Amjad, thanks for taking the time to respond. Can you please talk to Radon and work with him to remove the offending "unique and invisible" aspects, to make it so he can put his project back up? There must be some way to make it so that these projects can co-exist without causing any trouble, and it can probably done in a way that is much cheaper than bringing a lawsuit.

I disagree, the shell is in the best situation to do something about it. Or at least it would be, if there was a consistent way for programs to report to the shell how their argument parsing works.