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.
>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
No, that's not how this works. You don't need criminal activity to provide you with anonymity. You just need ANY other activity in order to get lost in the crowd[1].
Your flawed view is that nobody should have privacy because some bad guys might use privacy to do bad things. Privacy advocates are the opposite. We say everybody deserves privacy as a human right, even if on occasion some bad guys take advantage of the privacy.
>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.
My guess is that the level of abuse is much higher by the customers paying via monero, than the ones paying by card. My guess is also that abuse is not entirely without cost for Mullvad.
In other words the cost associated with the extra business that comes via Monero might be higher than the extra money that comes in.
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).
Hare has significantly more safety and security features than C. Bounds-checked slices, no uninitialized data, mandatory error handling, nullable pointer types, and others still. What it lacks that Rust users object to is a borrow checker.
You don't need a borrow checker -- there are many ways to avoid use-after-free bugs. They don't in Java, or Haskell, or Python, to name 3 languages I work in sometimes.
However, I really do think for a new "systems language" nowadays, you do want to look at how major security holes occur in practice, and have a good story on how users should avoid them.
These are all GC'd languages that run bytecode on an abstract virtual machine. They avoid use-after-free by just not-freeing, if necessary at the cost of leaking unbounded amounts of memory.
This doesn't invalidate the point that borrowing isn't the only way to solve this problem, but there are definitely classes of these bugs for which Rust's borrow checker is the only known production-ready solution that still has manual, deterministic memory management.
We do take security pretty seriously with Hare. To quote our crypto module's introduction as an example:
> Cryptography is a difficult, high-risk domain of programming. The life and well-being of your users may depend on your ability to implement cryptographic applications with due care. Please carefully read all of the documentation, double-check your work, and seek second opinions and independent review of your code. Our documentation and API design aims to prevent easy mistakes from being made, but it is no substitute for a good background in applied cryptography.
We have many safety features built into the language and the standard library is designed to be difficult to use incorrectly. I will address these concerns directly in a subsequent blog post covering the safety and security features of Hare.
The main problem is that some programmers view anything less than what Rust provides as morally unjustified.
When you say you take security pretty seriously, and mention the Hare crypto module, are you talking about the crypto module which silently falls back to storing secure data on the heap when Linux keyctl is not present on the platform?
Yes. As I reiterated many times in that thread, having your data stored in the heap does not introduce any immediate vulnerabilities, and this behavior is thoroughly documented in the standard library.
It is possible for two people who both take security seriously to come away with different take-aways. Once some CVEs are found in Hare you might have some fuel for your argument, but until then it's just speculation.
> Because rust inherently treats humans as fallible to a large extent. Which all of us are.
No it doesn't. It has a bypassable compile-time verified lifetime system, not an infallible programming guarantee. It leaves it entirely up to the developers to write correct and safe applications and libraries, and merely provides (powerful) tools to help.
(I realize this context was in avoiding common security bugs which are usually less likely in memory-safe languages, but it's important to not overstate the benefits.)
I think Rust kinda has a marketing problem: the myth that "Writing in Safe Rust automatically makes your code memory-safe". It doesn't (well, it does most of the time but it isn't guaranteed), but it rather defers the responsibility to other low-level system programmers writing Unsafe code behind the scenes. And oh boy they have a fuckton of responsibility... Stacked Borrows along with various sanitizers can help when writing unsafe code, but it isn't perfect. I highly recommend anyone trying out Rust for the safety guarantees to take a look at the Rustonomicon (https://doc.rust-lang.org/nomicon/), which debunks a lot of the misconceptions around safe/unsafe Rust.
In an ideal la-la land world, there exists an abstract interpreter that can consume safe Rust code and does not enforce any contracts upon the programmer (and hence will never have any undefined behavior). However, real world hardware definitely has contracts which developers have to obey (manually! because of the constraints of actual semiconductor physics! no compiler hand-holding here!). And on top of that all major OSes (Windows, MacOS, Linux) are written in C (so you need unsafe FFI to interact with the OS).
There seems to be a perception among Rust programmers that C's status as a defacto standard came to be in spite of C's contradictions, rather than as a result of them. Skimming the Rustonomicon just now left me with the impression that at least one Rust person gets it. Though it still seemed as if the author felt the need to choose their words very carefully, lest they "make the memory model people angry".
exactly. if i'm writing safe rust and encounter memory safety issues, their origin is with my dependencies, and my responsibility is limited to having chosen such dependencies.
In practice, this makes vulnerabilities in eg. argument parsers (like the recent "baron samedit" vulnerability in sudo) incredibly unlikely.
> the myth that "Writing in Safe Rust automatically makes your code memory-safe"
Of course you're right that that isn't true as stated, but I think it's interesting to try to situate this point along a continuum of other similar points:
1. C with Valgrind and sanitizers isn't always memory safe, because those tools are limited by test coverage.
2. Python isn't always memory safe, because many libraries including the standard library call into C code.
3. Pure Python that doesn't call into any C code isn't always memory safe, because the interpreter might have bugs.
4. Provably correct Ada with a provably correct compiler isn't always memory safe, because the proof checker, the compile-time hardware, or the runtime hardware might have bugs.
I think we all agree that there are important differences between 1 and 4, beyond the simple fact that the defects get less common as you go down the list. Here are some things that stand out to me:
- In cases #2 and below, the application code isn't "at fault" for any memory unsafety that comes up, and whatever code is at fault can be fixed to restore memory safety without changing the application.
- In case #1, there's no clear boundary in any sense between "safe code" (which we know isn't at fault for memory unsafety) and "unsafe code" (which might be at fault). There may be a distinction between code that's well covered by tests and code that isn't, for example, but it's often not easy to tell which is which. In case #2 and below, the boundary is pretty clear.
- In case #1, the amount of "unsafe code" in an application probably grows linearly with the size of the application, or maybe we just consider the whole application unsafe. But in cases #3 and #4, unsafe code is confined to low-level dependencies that get a lot of "battle testing" compared to how much code is in them. Case #2 is kind of a gray area, and we need to look at what dependencies the application is using.
So where should we situate Rust in that continuum? Is being able to write unsafe Rust code more or less risky than being able to call into C? It's certainly a lot more convenient to write an `unsafe` block than to cross the FFI barrier, and maybe that convenience is dangerous. On the other hand (contrary to some common misconceptions), unsafe Rust still benefits a lot from the borrow checker and other safety features, and it might end up having a lower rate of defects for that reason. Maybe it's too early to tell?
But anyway yes, I totally agree that the Rust community has a hard time getting the messaging right about how safe code and unsafe code work. But even though this discussion is really important to Rust, I'm not sure it's a "Rust problem" per se. I think it's actually quite difficult to talk clearly and correctly and precisely about memory safety in general.
This list is actually quite interesting for a few reasons.
One is that a large fraction of these security issues are not real, potentially exploitable vulnerabilities, but merely the fact that it is possible to abuse an API to subvert Rust's safety guarantees. These are things would, by the standards of other programming languages, not be worth even reporting and be considered user error.
The other is that a surprisingly large fraction of these are not from regular unsafe Rust code, but from misunderstanding the guarantees a C library makes when creating bindings for it. This is to be expected, as fully understanding those as a library is pretty difficult.
A total of one memory safety issue reported for an entire ecosystem this year so far also seems pretty good.
All in all, I think these are both pretty promising signs that the safety guarantees Rust provides working as intended.
Wait, that's all? On the entire Rust ecosystem those are the only ones found?
Everybody already knows Rust has unsafe blocks and C FFI. It is not invulnerable to those problems, Rust just makes it very clear where those problems may appear, and if you are smart, you will place most of your code outside of those regions.
Looks like Rust is much safer on practice than what I expected.
Note that unsafe does not contain anything. The problem propagates to the unsuspecting caller of claimed safe code.
Ending up compromised by a problem in tokio, Pin semantics, actix or all the necessary ffi bindings is no different than, say, a C program being compromised by a vulnerability in OpenSSL or libcurl.
A very significant number of memory issues in C stemmed from issues in such single high-profile dependency, so one should not undermine the threat of a bit of unsafe code in the corner of a library.
Not being perfect does not translate to not being better. Being safe by default and having compiler-enforced safety as a top design choice is great.
Rust is better.
It's very much human nature to trace the line in the sand juuuuuust right behind one's heels though, depicting everyone behind as bad and everyone ahead as zealots.
I did not say rust was not better. I said the statement was false, based on a misunderstanding of both the benefits of Rust and the problems of C many if which Rust is not immune to.
Rust is definitely better, hands down, but insisting on thinking code that interacts with unsafe blocks can be "safe by default" is a dangerously wrong mindset which also makes unsafe blocks proliferate without the necessary caution as the problem seem "contained". Anyone remember the actix unsafe saga?
But even though a program with unsafe blocks (read: all rust programs) are by definition not memory safe - calling a language memory safe on current platforms can to some extend even be considered a misnomer - the assistance provided by rust by default certainly helps make such programs much safer.
Well... if you consider the proportion of "lines of code (or projects) ever written in the history of a language" over "security issues found" then Rust will be probably losing.
I can assure you that Hare takes security more seriously than assuming the programmer is smart enough to do it right. I don't appreciate shallow takes which make unsympathetic judgements on the language which are not based in any understanding of how Hare actually works, and I've heard nothing but such takes for a week.
Hare does not prevent use-after-free, but it does prevent many other kinds of bugs which are common in C. I will go into greater detail in another blog post.
And that category of bugs (memory safety) is only avoidable if the unsafe code itself doesn't have undefined behavior (which responsibility is left to the programmer rather than the compiler). If unsafe code is compromised then it's still game over (hence the recent development of various tools/methods like Stacked Borrows in MIRI that checks potential errors outside the borrow checker, as well as various guidelines for developers to write safer unsafe code)
Safe Rust cannot ever cause undefined behavior, but Unsafe Rust can. The ultimate merit of Rust is that when you suspect any undefined behavior you only need to check the unsafe part, which is a much smaller percentage of your codebase (as opposed to C/C++ where you need to check the entirety of your code)
It is not enough to check your unsafe code for UB, you also need to make sure it does not violate the invariants Rust relies on to prove the safe code safe.
a very narrow sense representing 70% of all security vulnerabilities at microsoft and google (self-reported). i'd say it's a class of vulnerabilities worth eliminating, especially when the "cost" is getting a competent and standard package manager and a general focus on correctness that ultimately increases developer productivity and ergonomics (compared with C++, IME)
Honestly, I don't blame him, after the onslaught he's been defending against in every other thread since Hare's launch. It's really embarrassing to see that side of the Rust community acting this way.
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.
I think “incredibly bad” is overstating things quite a bit. Safety isn’t an all-or-nothing game. If it were, Rust would be useless because it’s not Ada or another formally verifiable language.
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.
I'm just curious here. 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".
Especially if my approach has single handedly created the largest body of copyleft / collaborative / open source software out there with massive amounts of actual collaboration.
The irony is so strong here. Basically jerks, who can't get along with others (including each other, witness the battles between SFC and SFLC etc etc) with little value creation themselves want to force their view on others, even though folks have already voted with their feet.
By all means create the Affero GPLv3. Try to get folks to write software for it. That's fine.
But don't pretend to be on some moral high ground speaking for developers / creators who wrote the code. Let them speak for themselves. And don't go back and having lost the effort to get Affero GPLv3 or whatever adopted close the various SAAS and Tivo loopholes, go back and say some old license has these terms.
> 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".
The exact same authority developers have when they tell their clients that they cannot run a 1,000,000 person site off the phone they forget to charge sometimes. Or even a designer telling a client their color scheme is poor (it clashes, isn't color-blind friendly, and renders poorly on anything smaller than a tablet)! It's a technical matter and they are paid SMEs.
They aren't saying Linus's goals are stupid. They're saying the methods he's using to achieve the goals are. Which makes sense. Because he's not a lawyer.
> They aren't saying Linus's goals are stupid. They're saying the methods he's using to achieve the goals are. Which makes sense.
So if lawyers were in charge and rampaged around suing the shit out of every company that made a mistake when using Linux, that would better suit Linus's goals? Only Linus can speak to Linus's goals, but I doubt this is what Linus really wants.
> if lawyers were in charge and rampaged around suing the shit out of every company that made a mistake when using Linux, that would better suit Linus's goals?
No. But if they went around sending demand letters that were complied with (because they came from a reputable law firm) by getting the code open sourced it would. I'm not saying these lawyers should be listened to. I'm saying some lawyers should. And excluding all lawyers is as dumb as trying to get funded for your FaceBook clone saying you only need the money to "hire a programmer" would be.
> Only Linus can speak to Linus's goals
This is nonsense. I might be wrong but I can certainly speak to his goals. We can even discuss what we think they are.
> 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".
This is like saying “If I want to write my code a certain way, what right do compiler authors and language designers have to tell me code contains ‘syntax errors’ and ‘obvious bugs’”. On some level you can write whatever code you want. But if you want it to work the way you intend, there’s some rules that have to be followed
> If I want to write my code a certain way, what right do compiler authors and language designers have to tell me code contains ‘syntax errors’ and ‘obvious bugs’
That's not a reasonable comparison.
1. Licenses are fundamentally open to interpretation, programming languages have specifications. Yes, the specifications and compiler aren't perfect, however, code is designed to be specific. Legal agreements on the other hands are very intentionally the opposite. Legal agreements consciously avoid being overly specific in order to be broad and all encompassing. Legal agreements fundamentally have access to (and are evaluated with respect to) the concepts of "fair" and "reasonable"; which very intentionally have no strict definition. You need to argue your case.
2. More importantly, licenses are contracts. They're a civil matter (not criminal). Meaning the copyright holder can chose whether or not they want to enforce their license. That's a fundamental right of being a copyright holder. If you consciously don't enforce, you may lose the right to enforce (at least fully), but that is the license holder's call.
There's lots of ways that licenses can be objectively wrong. They can contain content that renders them invalid, or wording that legally means something different from what the author intended. A lawyer has the "right" to point out such flaws, and refusing to consult a lawyer won't make those flaws go away.
You are of course right about copyright holders being able to chose whether to enforce their license (at least if they were smart enough to use a license that will actually stand up in court!)
This type of positioning by the SFC is horrendous.
Why do I have to follow the SFC rules / interpretation (by the way very flawed) when I write my own code.
Seriously, what gives them this right over my code. I reject this, even if GPL licensed.
Of course, I get the argument you and they are trying to make. By releasing stuff with GPL software I may have written, I've somehow bound myself to release my decryption keys, unlock my devices etc etc. You are making my point for me, that is NOT what most authors of GPLv2 licensed code want or agree to. And just saying "because lawyers" doesn't make it so.
This is a good example of the hazards of involving lawyers I think. Wet becomes dry and dry becomes wet.
You (presumably) live in a country with rule-of-law. That means that if you are involved in a court case related to your GPL code, the legal system in your country will determine the outcome. Refusing to consult with lawyer in advance about what the outcome of such a legal proceeding will probably be, isn't going to improve your odds!
I have no clue whether whatever SFC has been claiming about the legal status of GPL is true or not (quite frankly, I haven't bothered even looking at what they're saying). But if the legal system's interpretation of GPLv2 doesn't match what most authors want or agree to, that sounds like precisely the kind of thing authors should want a lawyer to tell them, so they have a chance to switch to a different license.
The issue is the legal system has, to date, largely followed the understood intent of the GPLv2.
Consulting with the SFC does nothing to advance anything.
Harald Welte has had great success getting folks to release source code. However, he does not threaten commercial use of GPL software, no unlock keys / signing keys etc are needed.
> 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".
The first part of the statement--if you want to license your code a certain way--your lawyer should be to work with you to find a way to legally do that. Unless you want something patently absurd like "I want a way to let me murder any idiots who use my code without any consequences whatsoever."
It's the parenthetical that's problematic: you can't control how the law will be interpreted, and if you've got an incorrect interpretation of the law, you'll be laughed out of the courtroom. See, for example, any sovereign citizen case.
Compare it to the GPLv3 (written by these expert lawyers).
Which is clearer, more understandable, just more rational?
Which is the license that has the larger adoption on more code used by more folks.
And despite all the claims here, intent is going to matter. When you sue Linus and say the GPL doesn't mean what he and everyone else actually creating this code think it means, then he's going to say, this was our intent. And you are going to have a VERY tall mountain to climb.
> Which is clearer, more understandable, just more rational?
Honestly, just quickly looking through the two licenses to answer a simple question... GPLv3 [1].
From a legal perspective, "simpler" documents tend to be less clear, because a lot more of the interpretation will rely on common law jurisprudence [2], and the "common" here doesn't mean "everybody agrees"--it in fact means "every jurisdiction has its own set of rules that may or may not translate directly in other jurisdiction."
> And despite all the claims here, intent is going to matter. When you sue Linus and say the GPL doesn't mean what he and everyone else actually creating this code think it means, then he's going to say, this was our intent. And you are going to have a VERY tall mountain to climb.
Given that a software license is close to a take-it-or-leave-it contract, ambiguous interpretations are generally going to be interpreted in favor of the person who has the take-it-or-leave-it option--which in this case is not going to be Linus and co.
[1] The criteria I used: "how do patents interact with this license." From what I can tell, GPLv2 technically doesn't actually contain a clause where the licensor grants the licensee any and all necessary patents--it instead talks about what happens if the code violates a third party's patent. Admittedly, reading the GPLv2 to not include a patent license grant is somewhat of a malicious reading, but the GPLv3's verbiage here is pretty explicit: "Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version."
[2] I'm limiting my analysis here to US jurisdictions, because that's what I know.
If GPLv3 had been GPLv2 plus patent stuff and a few other things it'd likely have been very welcomed.
For folks following along, the GPLv3 is more than 2x the length of the GPLv2
"If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product"
absolutely disagree with this paternalistic interpretation.. coders are typically literate. Your example claims some exaggerated illiterate premise and then uses that to say "talk to a lawyer instead" .. no comment beyond that since we obviously have different concepts of what rights of an author are...
If you want some examples of legal consequences you might not otherwise anticipate:
* Estoppel. Not going after someone when you are made aware of their violations may preclude you from ever being able to go after them.
* Severability. If one clause of your contract is unenforceable, the entire contract may become unenforceable unless you have a clause saying otherwise. (And even then, sometimes that won't apply!).
Taking the audience of HN as a reasonable sample of competent coders, I have seen more than a few commenters give very confident and very incorrect interpretations of the law. I am not so presumptuous to think that I am not in that class, although I do hope to do so more rarely than the average commenter.
And for what it's worth, I don't believe that the exaggerated premise I used was one that requires a lawyer to understand; it was merely an example that was so outrageous it would not be unreasonable for a lawyer to tell you that it was impossible for you to do what you want to do. An example that is not so outrageous is if you want to release something into the public domain--for there are jurisdictions where giving up all of your rights as an author is impossible.
>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.
You fail to understand how copyright works. If I'm the creator of the work, I have the copyright to it.
And yes, I'd be happy to represent myself if SFC came along and told me I could or couldn't do something with the code I wrote because that makes no sense. I can choose a license, I can dual license, I can re-license future releases and I can stop providing updates under any of those licenses.
So sure, if you and the SFC want to go after me for my code, go for it.
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.
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.
> If I'm the creator of the work, I have the copyright to it.
Not necessarily. For example, work for hire, or copyright being assigned to the employer. Or maybe the work itself isn't copyrightable in the first place. There's even a fun provision where US government work doesn't have any copyright in the first place! You might also have transferred the copyright of your work after you created it in a way which doesn't give you any retained rights.
in the USA there is strong copyright for the author of the work in question. Work-for-hire is well understood in Chapter 1 of any book on that topic. Secondly, a court appearance is not required to be an author and therefore copyright holder. Suggestions that "if you are not able to make a court appearance then XYZ and etc" .. is fallacious to start with, condescending and sounds a lot like an attorney arrogance. NOLO Press, read my lips
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.
Unsourced. Low information content. You're throwing a whole lot of vague shade around in this thread. overboard2 asked you for an example, that was an opportunity to get specific, but your response is to make vague comparisons to 4chan?
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.
I would argue this confirms what the OP said cmake is really not very friendly to the user (not developer). Reading through the cmake sources for options is equivalent to "read the source".
But you only have to do this if you don't want to run an actual GUI or ncurses UI which does this for you for some reason ? What would you suggest instead ?
(and if your meta-build system does not allow to do that, I'm sorry but I'll have to build a meta-meta-build-system on top of it which implements it and no one will like it)
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.
I actually wouldn't mind you going into detail about why naming systems like ENS do not benefit from being on a blockchain, as they seem to me to be one of the more obvious use cases.
If the default path of technology were such that our current DNS system were based on a blockchain smart contract system, and then someone proposed a new system with single points of failure, reliant on trusted recursive resolvers, registrar middlemen, a trusted root zone for every country, and a tacked-on CA system that requires fully trusting N-of-N organizations dotted across every jurisdiction on the globe whose job is to verify address resolution from multiple network perspectives, plus OCSP and CT servers to enforce revocations and maintain certificate history - both of which are problems directly caused by a non-blockchain system design - they would be laughed out.
With ENS:
* The blockchain itself is the root of trust, because every name entry has an associated owner entry and every owner entry has a public key entry, which can be used to encrypt and authenticate content.
* Name resolution can be performed by anyone running the client software, by connecting to anyone else running the client software.
* Users can register names directly by using a piece of software, without requiring registrar companies.
* 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.
* 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.
If you want to go into "extreme detail", now is the time. Please tell me why I am wrong.
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.
> 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.
What properties? What I've listed are operational requirements, which blockchain systems have much less of.
Some desirable properties I can think of are reliability, security, and geographic redundancy, all of which a blockchain system could match or exceed.
Getting rid of the CA/OCSP/CT system would be a huge start security-wise, and getting rid of trusted operators for particular TLDs would be helpful reliability-wise.
> 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.
"The chain" is a geographically distributed database, an ideal kind of data structure for keeping track of names. If forked, the database is no longer useful.
The protocol's purpose is to maintain that data structure, which is enough. There doesn't need to be an "otherwise", because that data structure has desirable properties that no other type of protocol can replicate.
> 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 do believe that a blockchain is actually much cheaper and more efficient than the network of thousands of licensed and privileged organizations that we currently have. A proof-of-work blockchain is not more efficient, of course, but a proof-of-stake blockchain is. You could eliminate a lot of jobs in devops and reliability engineering, and replace them with hobbyists running blockchain client software on a home server.
> Which is the single point of failure.
Properly designed blockchains have no single point of failure. The only point of failure is the protocol itself, which you could also say about DNS. Ethereum has had a massive target on its back for many years now, yet has had zero downtime.
> 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.
The fundamental purpose of a blockchain is to come to consensus on data without any trusted parties. When you query data from a blockchain like Ethereum, that data is signed off by the network's consensus algorithm, so you can trust that it hasn't been altered. Data integrity is a basic blockchain concept.
On the contrary, it's your recursive resolver in the current DNS system that you have no way of knowing is sending you fake records. As client DNSSEC adoption is effectively nonexistent (and registrar and domain adoption is spotty too), your recursive resolver can send you just about anything. Unless you use some other trust mechanism, you have no idea whether the IP it gives you for a certain name is valid.
> 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.
Not true. People do that because it's convenient, but all you need to start resolving is to download geth and query the resolver contract. You don't need any middlemen.
> 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.
That's true, but a swarm of unprivileged computers with an m-of-n trust profile and uptime guarantee is preferable to your registrar with a 1-of-1 trust profile and uptime guarantee. The blockchain behaves predictably as long as m-of-n validators are honest - a company behaves however it wants to, and could throw you under the bus at any point due to incompetence or corporate malice (see the story of "How I Lost My $50000 Twitter Username").
> This is also incorrect, you're trusting parties to host the system on the blockchain which are the "privileged servers".
The trust profile is totally different, though. DNS requires 1-of-1 trust for each TLD. ENS requires m-of-n trust across a swarm.
If one DNS TLD server goes down or defects, an entire section of the internet goes down. If one blockchain validator goes down or defects, the network boots them off (validator exit) and nothing happens.
> The solution here would be to just add more redundancy to DNS
DNS is already very redundant. How would you add more reliability without completely rearchitecting the protocol, or adding a concept of "a chain of blocks of data" that registries pass around and vote on the validity of?
> blockchains again don't do anything special.
We might have to agree to disagree. I think it's self-evident that something "special" was achieved, otherwise people would have forgotten about them a decade ago and moved on.
>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 :)
The other problem is that during a Git conflict resolution, other files matching that glob get dropped into your source tree. Globbing these up is…never going to go well.
>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.
> 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.
I've seen a lot of people make that mistake too. A whole ton. But you can't tell me that you form your opinions on new technologies based on listening to people explain them poorly and try to shoehorn them where they don't belong.
> 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.
They could have been avoided, yes, but someone chose to solve them so now they're solved. I don't really understand your point. Are you saying that nobody should have been allowed to solve those problems?
> The sense of struggle and "progression" here is entirely made up.
It's unclear to me what you mean by "sense of struggle". But a decade ago the technology had several unfavorable properties and limitations, and now it no longer has those certain unfavorable properties and limitations. Is that not progress?
> You're repeating the same mistake as the critics by even talking about these things.
What mistake am I making, why is it the same as blockchain critics, and why am I making such a mistake by talking about the quality of the forum discussions I participate in?
> The fact that the discussion is even framed in these terms as if these problems need to be solved
I don't frame things that way; I don't view most things in the world as "problems needing to be solved". What I do see is processes that can be streamlined through the use of certain technologies.
I don't necessarily believe that this RFC is helpful, or that blockchain is a useful technology in the context of BGP, but you're making a sweeping statement about the nature of all discussion of blockchain technology, a statement that I believe to be overgeneralized and essentially incorrect.
> in some particularly obscure fashion
Many of the systems that blockchains aim to improve on are already particularly obscure. Naming systems, ownership registries, and financial derivatives come to mind.
But more fundamentally, the complexity of a system's software implementation does not directly correlate with its utility as you seem to imply. Plenty of software projects out there are very complex, yet still manage to be very useful.
> Because it is actually useless.
None of your comment really supports this conclusion.
