throwaway82652

No? I don't know where you got that from.

You should be implementing a borrow checker or something like it. It's irresponsible not to do that. I'm serious about this. We know how to totally stop most use-after-free bugs during static analysis now, this is a tool that can be implemented in any language, so people should just do it. If you ask me the status quo moved a long time ago. This has nothing to do with Rust.

Also I was wrong before and you were out of line. Matthew wasn't trolling, he never said you should be held criminally liable. You just made that criminal part up for no reason. Anyone should be held socially liable and shamed if their project has bad security and they refuse to fix it after they knew about it. I think you would even agree with that.

You just need ANY other activity in order to get lost in the crowd

And that's irrelevant because these tools are explicitly built for criminals to use them. I'm actually quoting what the designers of these systems have said, this isn't my opinion. When you say "ANY other activity" that also means criminal activity gets lumped in there, I don't know why you're denying this. You're probably not a criminal but if you're using this then you're intentionally making criminals your company and you will pay for the effects of that in one way or another. That's the part where I'm speaking to you from experience. You just can't make an anonymized system like this that also isn't a lucrative target for criminals, such a thing doesn't exist. Is it unfortunate for those who aren't criminals and actually need privacy? Absolutely, but this is the reality of the situation. There's no easy solution. If someone is telling you that this isn't an issue then they're just lying to you, get mad at them instead of me.

Your flawed view is that nobody should have privacy because some bad guys might use privacy to do bad things.

No, this also isn't even remotely close to what my actual view is. You just blatantly made this up for no reason. Why are you doing this?

This is yet another reason that it's so exhausting to talk about this, not only are you spreading misinformation about this project but you're also spreading misinformation about me. Misinformation and disinformation is actually incredibly common in these low-trust environments. If you think it's bad, I agree, it's actually incredibly shameful that some people try to use "privacy" as a cover to spread misinformation, but that's something else that you have to accept and deal with and insulate yourself from if you take this route. Please do a better job in the future and don't bring yourself down to this level of empty rhetoric. You're letting the liars and criminals win.

If you're acting this way because you see this route as some kind of moral outlet, I would suggest that you stop and find another one. This one is ethically gray and if you stick with it, you'll be peer pressured into excusing a lot of things that you're probably not comfortable with in the name of "privacy" at the expense of everything else. The moral rationalizations coming from these projects are strong, but are ultimately willful blind spots informed by money-making and capitalism just like everything else. Don't say that nobody warned you.

If there is another forum I would hope similar comments are also downvoted or deleted there because it's completely unrelated to the discussion, and you're also taking the opportunity to take cheap political shots at easy targets. Don't do that. Dr. Fauci doesn't even work for the CDC. You're better than this, you don't have to set up these rhetorical traps to have a discussion.

Even if you aren't a criminal, the fact is that privacy tools of this nature are explicitly relying on having enough volume of criminals and other illicit users to provide cover for you. This is what they're designed to do, the designers of these systems will openly admit to it. You can make your own judgement on whether you're ok with that, but it doesn't help to deny what's actually happening.

https://en.wikipedia.org/wiki/Monero#Illicit_use

That comment is definitely out of line and trolling, but the author's attitude towards safety and security is still incredibly bad. Two wrongs don't make a right. I'm dismayed to see more new languages copying the safety and security features of C (i.e. nothing).

they would be laughed out.

No they wouldn't because almost all of those properties are actually desirable, and the only real achievement of ENS is to approximate all of that. Remember that the whole reason you're even using a blockchain (in the Ethereum sense) is because it artificially makes it too expensive for ordinary people to fork the chain. It has no purpose otherwise. If you can come up with a cheaper and more efficient way to do that then there's no reason to use a blockchain. I'll address each of your points.

The blockchain itself is the root of trust

Which is the single point of failure.

Name resolution can be performed by anyone running the client software, by connecting to anyone else running the client software.

This is not actually desirable, you have no way of knowing whether someone is actually doing this correctly and not sending you fake records unless you use some other trust mechanism.

Users can register names directly by using a piece of software, without requiring registrar companies.

This is not true at all because most users need to go through a number of middlemen to interact with the blockchain in any way. In practical terms you aren't getting rid of registrar companies by doing this, you're just farming the task out to miners/validators who get paid to run the smart contract.

The whole system can be built within a single root zone, because no parties need to be trusted to host the system on privileged servers.

This is also incorrect, you're trusting parties to host the system on the blockchain which are the "privileged servers".

In practice the system is highly distributed and available, so has had 100.00% uptime for all zones since launch, a higher uptime than DNS.

The solution here would be to just add more redundancy to DNS, blockchains again don't do anything special.

There's no name calling, "stupid" is the exact word you used. I'm stupider than a lawyer when it comes to all the details of contract law, because I didn't study it as much as they do. If you aren't a lawyer, then you probably are too. Again, nothing wrong with admitting it. You and I can't know everything. It's actually arrogant and insulting to claim that you know more than a skilled lawyer or attorney just because you wrote some code, I would suggest not doing that.

There seems to be a modern confusion that the folks NOT doing any of the work in writing code have all sorts of rights with respect to it (or time of a dev to fix their bugs). False.

I'm sorry but this makes no sense, it's weird how often I see this sentiment in open source. If you hired a lawyer to represent you and give you legal advice and defend you and court (which is multiple full time jobs) then you're paying them to do a job for you. You're not giving any of your rights away. You don't have to choose to hire SF Conservancy, you can hire another firm.

Pot, meet kettle.

No, this is incredibly wrong. The source here is me. You can choose to not believe me, but it's a source. I'm sorry but I just don't illegally carry a tape recorder into every meeting I go to just to prove something to a person on the internet. If you want me to elaborate then just ask a specific question, please stop with these "gotcha" tactics because they don't do anything. If you were referring to this person's writings, the article that was already posted is a source.

If I as a developer want to license my code a certain way (and enforce that license in a certain way) what authority do these lawyers have to tell me I'm "stupid".

Are you willing to represent yourself in court? If the answer is no, then that's an admission you are stupider than a lawyer when it comes to legal matters. Nothing wrong with it, I have no problem admitting it myself. Let the programmers handle the programming and let the lawyers handle the law.

It's the same kind of unsourced low-information content focused on personal grievances that you would find in an angry twitter or 4chan comment. It's just intellectually lazy and bad writing, this person is smart enough not to do it but does it anyway. If you need me to explain why this is undesirable, then we probably don't have much else to talk about.

From the lawyers I've spoken to about this, Linus's view on the GPL and the chosen enforcement strategy has long been known to be nonsense. But nothing will change as long as the kernel developers are intentionally burying their head in the sand and acting like they know better than the legal system.

You can just look up the Linux Foundation's tax statements, they're publicly available.

Bryan Lunduke's recent writings are a bad source, they consist almost entirely of reactionary trolling. No idea why he gets any readership.

Use cmake-gui and it lists all the options for you. Or for the manual method, search in the project's cmake sources for lines starting with "option(".

I'm sorry but absolutely none of those applications need blockchains or even benefit from them at all. If you want to discuss this I could go into extreme detail why that's the case. I can understand being excited about the promises made by them but at some point we all need a good reality check. Having curiosity doesn't suggest any particular kind of acceptance, we can actually accept that something is universally useless and not worth our time. I'm not saying this because I want to crap on people's startups, I'm saying this because they could make a lot better products if they weren't getting wrapped up in this.

5. automake documentation discourages developers from globbing source files in source directories, and insists they list them individually. It's silly and just results in needless running of configure.

No it's not silly, realistically you can't actually do that anywhere without re-running configure. Any build system based on directory trees will have this limitation. See meson's docs for more on this: https://mesonbuild.com/FAQ.html#why-cant-i-specify-target-fi...

I also came here to comment that libtool is totally useless on modern systems and I hope it gets removed or made optional, but you beat me to it :)

take personal offense to me even daring to suggest that blockchain technology isn't completely useless

Because it is actually useless. I've seen tons of people trying to explain the current state of it and a lot of them do the exact same thing but in reverse: falling back on very basic mistakes made by the specific design of Bitcoin and taking that as a given of how they need to design systems. Everyone who talks about energy usage, scaling, and the oracle problem in this way is missing that these problems could have been entirely avoided by just not using blockchains in the first place. The sense of struggle and "progression" here is entirely made up. You're repeating the same mistake as the critics by even talking about these things. The fact that the discussion is even framed in these terms as if these problems need to be solved in some particularly obscure fashion is a net loss for everyone involved, including you.

It doesn't really make sense to put your confidence in something questionable because something else happens to be bad. I get that you probably have a better explanation but this comment isn't explaining it and instead is just taking an opportunity to dunk on people, if you want to have serious discussions don't make any more comments like this. If you really want to improve communication then please do your part to communicate better.

Completely disregarding any advances in cryptography or consensus

Because those advances exist in spite of blockchains. I wish blockchains were a useful technology, but they actually aren't. I've seen zero advances in distributed ledgers that are actually helped by blockchains. The use of a blockchain strictly makes it worse. And even past that I've seen very, very few situations where the whole idea of a distributed ledger even makes sense to begin with.

If you want to communicate a way this technology is useful then just do it and make me care, don't waste time going on about merkle trees and consensus algorithms and getting sucked into the same reductionist trap of singling out some minor technical details.

In some aspects it does, for example a lot of Gnome apps have very minimal designs. That's ok for individual apps. The problem is, you can't really apply that to a chat tool that needs to be used by everyone in a large community. The problem space itself requires you to deal with a lot of complex and competing interests and make difficult compromises, so you can't always please the minimalists trying to run IRC bots off a ESP32.

I think IRC's lack of features is actually an advantage and not a disadvantage.

It's an advantage in the sense that if you want those features, you get to implement them yourself in a very complex series of IRC bots and server plugins.

In this comment, it appears you took the word "expert" and defined it to mean "people who aren't actually experts" and then used that to dismiss them. I hope you can understand this isn't a useful way to approach the conversation.

If you're getting accused of being racist and bigoted towards gay people, Jews, and Muslims, it would help to make an honest and friendly effort to spend your time reaching out and helping those people, rather than getting distracted with what these "political hacks" are saying.

No, it's not even close to that. Analogies aren't that good of a tool to use here.

No, it isn't. Pulseaudio is based on a push model, which is completely broken.

These two statements are both very wrong. The push model is absolutely not broken, it's actually better for media players, networked sound and other non-pro-audio applications because it uses less power and can do more efficient buffering strategies. You're right that it's not good for pro-audio and other latency-sensitive applications, but pulseaudio was not designed to do that on purpose because jack already filled that niche. The pull model has to wake up every application every quantum on a strict deadline to do processing. In some situations pulseaudio should still be able to provide the smallest power usage compared to pipewire, even just continuing to use the pulseaudio API to do buffering on top of pipewire should be a benefit for applications that want it.

Even if it was broken (it's not), that would be an aspect of the design, not the code itself. The code itself is structured in mostly the same way as pipewire.

Can someone explain to me what pipewire's goal is? to be a better pulseaudio?

Yes, and also the goal is to support video in addition to audio.

if so, in what way is it trying to be better?

Well in addition to supporting video, it also supports jack clients without needing to run a separate server. There are a few other things like better security policies, but those are the major ones.

also, how's the codebase quality? from what i heard, pulse's codebase is a mess, so if it can improve in that sense, i guess that's a win (?)

Pulseaudio's code is fine and pipewire is about the same, it's a relatively small core daemon with most of the major functionality split out into a large collection of loadable modules.

why does it do video?

A few reasons, but the major one is because video on Linux has the same problem as audio: the low-level device API (V4L) can only be used by one program at a time. This leads to failures if you try to do something like access your webcam in two applications at the same time. Most applications should basically not be using ALSA or V4L directly to access devices for this reason. A sound server like pulseaudio is the typical way to mux/demux the audio devices to allow multiple applications to access it at once, and now pipewire extends that to video.

is trying to do media capture like OBS or be a compositor like wayland?

Neither, it's used to route video sources between programs. Media players and cameras and Wayland compositors that want to do screencasting can send their video into pipewire; casting programs like OBS or any ffmpeg-based tools can receive any of these video streams from pipewire and do whatever they want with them, or could also output to pipewire so another program can consume their output. If applications support it then the idea is you'll be able to easily connect together any two applications that produce/consume video and it'll all just work.

Not really, the question is how the organization is classified. Linux Foundation is a 501(c)(6) so they can sponsor some people but it's only for the purposes of furthering "common business interests" and not for profit.

That's an extremely small percentage, most Linux developers aren't sponsored by the Linux Foundation. The majority of their expenses go towards events and training.

I have no idea which press release you're talking about, every search I did on the subject turned up this news article or another one with very similar content, where there's no official press release: https://www.theregister.com/2021/11/10/system76_gnome_deskto...

Searching through the foundation's news posts shows only one press release about system76, which is positive in tone and isn't related to any argument: https://foundation.gnome.org/?s=system76

If you could post this press release so I could read it, that would be great. Maybe I'm just stupid and I missed something obvious. But I think you may be misremembering this.

If your distribution is already content to ignore any efforts at standardization in favor of "unique aspects" then I don't see what the problem is. You can go about your business and ignore systemd, or choose to adopt it on its merits. It's entirely up to you, nobody is using any status to push opinions on anyone.

Also you're ignoring the last part of that sentence: "where there's really no point at all in doing so". That's the most important part. If a distro has a real reason to deviate then that's fine. If a distro is deviating for no reason then that's doing a disservice to its users, and you can expect anyone who ships other things for that distro to be upset with them for pointlessly making extra work for everyone else. It's not just the systemd developers who will be inconvenienced.