This is obviously not true. If `serde` resided at `erickt/serde` (as the counterproposal for Rust would've had it), I could create `erict/serde` or `erick-t/serde` or any other variations of erickt's handle.
The only way this is 'solved' is if some third party authority hands out top level names and refuses to register names that are similar to other names for some definition of similar. The number of levels between top level and package name is irrelevant.
Well, you could also solve it by saying that the post slash names are unique. ie. There can't exist zardeh/serde if erickt/serde already exists. Then the author-name works as a logical checksum, and you aren't any worse off than you were with a global namespace.
The purpose of a namespace is to make it possible to disambiguate two otherwise identical identifiers. If you force package names to be unique across all namespaces, then you don't have namespaces at all, you just have a single global namespace where you're forced to prepend an author name to the package name.
While attacking a single package would be possible, covering any interesting amount of "typo"-space would require registering huge amounts of namespaces.
If package manager developers are smart, the allocation of namespaces is also handled externally and associated with some cost (e. g. domain names).
Therefore these kinds of attacks become impractical.
While a package manager could require something like a domain name to authenticate, its much more common for them to require something with a much lower barrier to entry, like a GitHub account. I don't agree that this design decision means they are 'not smart' (nor do I think having a single namespace is a 'beginner mistake,' but whatever).
Package managers like these approach social networks, which has many advantages but carries the disadvantage of opening users to attacks that resemble social network phishing attacks. We could mitigate this by rolling back to package managers with higher barriers to entry, but I think that is not likely to happen.
You clearly would prefer to use a more adjudicated, managed package manager, with a higher barrier to publish and stronger rules about naming. That's a reasonable thing to want, but it would be better of you if you didn't act like people who want something which conflicts with that goal are stupid.
this is yet another reason why i really wished rust had went for namespaced packaging on crates.io. i like so many of the decisions the rust team made, but not this one.
Say that a popular package lives at `jack/foo`. An attacker needs only register `jakc` and create a package `foo`, and now anyone typing `blah install jakc/foo` is owned. There's a reason why "namespacing" isn't listed under the "Defenses against typo squatting" section.
but if you are targeting a package `someuser/popularpackage` can you not just register your own malicious `popularpackage` under a typo namespace like `smoeuser`?
Yes, but my thought was it gives a bit more "data" to work with on the package manager's side.
They can see someone registering popular package names under something with a similar namespace and can flag them for manual review (which can be done for namespace-less packages, but there will be much more noise), they can apply things like "This is the first time you are installing a package from 'smoeuser' would you like to continue?", or even require adding a specific namespace "out of band" depending on how paranoid it wants to be.
That's a good point, but honestly I wouldn't be able to tell you the account names of any of the packages i use regularly.
And unless the account name of the package maintainers is brought front-and-center, you aren't necessarily going to know it shouldn't be different until it's too late.
A user doesn't need to be able to recognize the account name, that's the purpose of your aforementioned prompt. Let's consider the possible scenarios for installing "foo/bar":
I. I've installed anything from the author "foo" before
on this machine, implying that I trust "foo".
A. On a system with namespaced packages, I attempt to
install "fpp/bar". I've never installed anything
from the author "fpp" before, so I get a prompt.
B. On a system without namespaced packages, I attempt
to install "bsr".
1. If "bsr" is by an author I trust, then it will be
installed. This will be confusing, but is not a
security vulnerability. because this author is
already running code on my machines.
2. If "bsr" is by an author I don't trust, then I get
a prompt, as in scenario I.A.
II. I've never installed anything from the author "foo"
before on this machine.
A. On a system with namespaced packages, I attempt to
install "fpp/bar". The system prompts me, as in
scenario I.A., but because I expect this prompt I
don't bother reading it and blindly accept it. The
prompt does reiterate the name of the author, but if
I didn't catch the typo the first time, there's
little chance I'll catch the typo this time.
Remember: the value of the prompt is not the
reiteration of the name, it's in its unexpected
nature, because research has repeatedly shown
that users, even power users, do not bother
reading routine prompts (this is why, e.g., Chrome
no longer allows users to bypass the enormously
scary warning page that appears when a secure site
has a certificate error). My system gets owned.
B. On a system without namespaced packages, I attempt
to install "bsr". The system prompts me, as in
scenario I.A., but because I expect this prompt I
don't bother reading it and blindly accept it. My
system gets owned.
A more complete version of the solution that you're proposing would be to have an actual implementation of a web of trust, but even that doesn't solve all the security problems inherent to package repositories.
I think dismissing anything invented after 1960/not invented at Google counts as "inflexible and unadaptable; unable to keep up with new languages or idioms".
I don't think anyone considers Python or Java modern.
Nevertheless, this isn't about where adoption comes from, it's about how the language design was influenced by the advancements in language design in the last 40 years.
> I don't think anyone considers Python or Java modern.
This is why I put "modern" in quotes; these languages are "modern" relative to the 1960s-era languages.
> Nevertheless, this isn't about where adoption comes from, it's about how the language design was influenced by the advancements in language design in the last 40 years.
Precisely. The OP implied that Go programmers are "bad programmers" because they can't adapt to post-1960s languages. I countered his hypothesis by pointing out that the lion's share of Go developers were previously competent Python, Ruby, JavaScript, or Java developers. If his hypothesis were correct, one would expect the Go community to be primarily C expats.
For whatever reason, a large swath of developers find the features Go adds to be more useful than the "advancements" Go omits (or perhaps they just find value in the omission of those "advancements" altogether). At any rate, Go's popularity can't be reasonably attributed to graybeard developers who can't grok Java.
The problem is that the question is in the wrong context. Somebody is trying very hard to do something despite those constraints. For free. Why would you even try to discourage him to do so ?
Since when trolling convinced somebody of anything?
This was definitly not the intent of the troll, just a joke. But a badly executed one. It's like going to a political meeting, hearing somebody's plan to improve economy, and as a question asking him why not just change country. It makes little sense.
Plus, everybody should consider the resume of the guy, cause he is not just a newcomer trying to show off. He is a hell of a good dev.
I don't believe that the question was meant to be a joke or a trolling attempt.
The guy's competence isn't the issue. It's the requirements of what the fix can and cannot do.
_Everything_ is a mess due to the massive technical debt of never improving key parts of the runtime.
I mean what's the point of a runtime where adding threads makes things magnitudes slower than running in a single-thread?
"But that's just the state right now, they will fix this!"
No, they won't. Just as a perspective: People usually fight over a single percent of improvement or less when working on runtime concurrency. Nobody just goes in and fixes _magnitudes_ of performance issues without rethinking what has been done and picking a completely different approach.
This is not about making things "faster". This is literally going from doing necessary work to discovering a way of not having to do the work at all anymore.
That's just not going to happen. Neither locks nor reference counting have anywhere near this optimization potential given the current language semantics.
I think the whole (C)Python community missed the train more than a decade ago.
Things that necessarily had to happen just didn't happen.
Many communities and groups of developers "professionalize" over time. This doesn't seem to have happened in Python.
Just an example: C extensions. It has been clear for at least a decade that the existing C interface won't work for threading, "real" garbage collection, etc.
What would have been smart: Providing a better interface 10 years ago, effectively giving C ext devs 10 years of time to migrate their code. This way efforts to remove the GIL today would have to satisfy one fewer constraint that's currently crippling all of the efforts.
Same with a lot of other things ... getting rid of the GIL would have required changes to various parts of the stack over the years (GC, language -> Python 3?, APIs ...), turning the actual removal of the GIL just into a final act of a multi-step process.
What actually happened: Nothing. And now they just try to break the large lock into millions of smaller locks ... in 2016. WAT? This just tells me that key people in the Python community never really gave a damn about the issue and therefore this guy will waste his time.
I have never expected Python's demise, but it now seems that largely its culture and not its lacking technology brought it down for good. From my perspective, they should have never released Python 3 with a GIL. That's what broke Python's neck, finally.
Interesting train of thought. So if I understand correctly the gist of it is that it starts to becomes so costly to fix Python than to use another language that already has threading...so why not just use another language.
Why not use another language? I think it's a perfectly valid question for that guy to ask.
My personal opinion on "Why not use another language" is a bit different though:
Adopting a different language might make sense – not necessarily for technical reasons but for cultural. The technical issues could have been addressed in time, and the language would be in a much better situation today.
The fact that the technical issues have not been addressed for such a long time shows a clear lack of leadership and focus. I think these cultural issues are a bigger problem than the technical issues. You can fix code, but you can't fix people.
Yes, Scala is great. Way ahead in terms of providing developers with useful tools compared to most other languages. (It's not the usual run-of-the-mill language which takes Java and adds some syntactic sugar, so some effort in learning and understanding the language is required.)
