This is not a solution. The average rent is still $1832, which is still unaffordable for people in Denver making the median income of $54.3k if you apply the rule of thumb where rent shouldn't exceed 30% of your monthly income.
Ah yes, woke, the word used to describe something disliked.
That's a misrepresentation of what's actually going on in the R4L project. Volunteers are enabling support for it within the kernel to allow for rust drivers in a way that explicitly does not require existing maintainers to change how they maintain their parts of the kernel. Maintaining rust support and the APIs consumed by Rust is the job of R4L and doesn't require any work from the existing maintainers who are allowed to make changes to their C that breaks Rust where the Rust will then be adjusted accordingly.
Unfortunately yes, they'll send you a C&D if you pop up on an Oracle lawyer's radar. A coworker of mine had a course named "Rust for JavaScript developers" and received a C&D from Oracle.
1. I can pin my json parser dependency and literally never update it again
2. And how many times have we seen 20 lines of C backfire with some sort of memory safety issue.
3. First off, i'd go out on a limb and say the number of attacks from a well-established (or even a naive one) rust json parsing library is dwarfed by the number of attacks from adhoc config parsers written in C with some overlooked memory safety issue.
4. Usually being the key word, tons of adhoc config formats have weird shit in them. With json (or yaml/toml) you know what you're getting into and you immediately know what you're able and unable to do.
It works great for 90% of use cases, but getting that last 10% to work is really really hard so Bun (and node 22 which supports the same thing with an experimental) just throws an error in those cases. The most notable thing is `require`-ing an async ESM module from CJS, because require is a synchronous call you cant just async-ify it trivially.
Mostly curious, why do you care about the readability of the generated JS? Surely if you need to debug something for a production bundle you can use source maps.
One thing I'm not sure about when reading their policy is what'll happen in another kik situation. If someone were to claim the scope Microsoft (for example) that had no relation to Microsoft and then Microsoft came along and wanted the scope what would happen?
If MS got the scope what would happen to the packages in that scope, or if MS didn't get it what is done to clearly communicate that this is an unofficial account (presumably) asking on MS' behalf? In this early on period I'd expect a lot of people to claim the scopes of notable companies and these companies might take issue with that if they choose to use jsr down the line.
We do intend to take a more editorial approach to scopes, and assign scopes to users in a way we think is more intuitive for end users of JSR. We have reserved some obvious scope names already, but in the future, we'd likely entertain requests to reassign ownership of scopes for the benefit of the broader user community (as in the case of a brand owner requesting ownership of their brand name).
So in the case that a user published "@cocacola/foo", previously published versions of "@cocacola/foo" would remain available indefinitely (unless they were found to be malicious), but we would likely be willing to assign ownership of the "@cocacola" scope to a representative from that brand/company if they asked for it and we could verify their identity. The original author of "@cocacola/foo" would need to publish the module going forward under a different scope.
> but in the future, we'd likely entertain requests to reassign ownership of scopes for the benefit of the broader user community (as in the case of a brand owner requesting ownership of their brand name).
It would be great to find a way of structuring these registries/repositories in a way so there wouldn't be any name collisions, and also avoid the built-in support for companies to take names away from individuals.
Thankfully JSR won't be capable of a left-pad situation where packages can be unpublished - published packages are immutable[1].
As for the potential for disagreements over whether or not a scope should be transferred, that is a big reason why we want to figure out community involvement in governance sooner rather than later. We are gathering potential volunteers who want to discuss becoming a community moderator - if anyone would be potentially interested, they can sign up to join that conversation[2].
2. Use some pre-existing centralized name registry (e.g. domain names).
I don't know why the JS ecosystem is so resistant to either solution. Both are proven options (#1 used by COM, #2 used by Java). They do mean longer package names, but surely that's a small price to pay for a resilient future-proof solution? And besides, who really cares about long dependency names and why?
In the example of "@cocacola/foo" would it allow for the "@cocacola/foo" package to be updated with new versions by the new owners? Or would the foo package essentially be archived and read-only from this point on?
Domain expiration is rare, and virtually only happens when the related projects are dead anyways; freeze existing packages (no more updates until the original key for the domain comes back online, with manual override by registry administrators for edge cases) and have a reasonable waiting period (a couple of months to a year) before allowing the new owner to use the namespace (with different project names within).
Use URN instead of just a domain name. A domain name (with some schema) is obviously a subset, but anyone who doesn't want or need one can then use uuid: URNs.
The XML ecosystem did it that way for namespaces, and I think that it is still the most flexible and the most future-proof approach, since you can always add new schemas as needed.
Not if the system is built for DNS first. If a company/individual/organisation has a domain name, they are expected to use the domain. It is much less of an issue if someone has kik.users.registry.com when the company publishes packages under kik.com.
Even with their constraints they could have made this nicer, especially around the default formatter. Always requiring an explicit formatter is a classic example of Java being unnecessarily verbose, `\{ ` already wasn't permitted by previous java compilers as it was an unknown escape sequence so we could have nicer templates for the stock formatting like "\{foo} bar".
