From what I gather this is done to persist the sort order. All calls within the same millisecond will get the same timestamp component so that can't be used to sort the ULIDs. So the "random" part is incremented and the resulting ULIDs can still be sorted by the order of function calls. This wouldn't be possible if the random part were truly random. I'm not sure this is a good idea but that is what I understood from the spec.
Definitely didn't know that, thanks for that insight, really appreciate it! I always just assumed they were hashed but never really bothered to check. V4 shouldn't have this problem, right?
Very true and important to state, UUIDs on their own at most provide obscurity, not security.
Can the MAC address of the host that is used for some versions be extracted/read from the UUID or maybe inferred by observing a number of UUIDs?
I really liked this article but I feel it misses one somewhat important point about using incremental numbers: They are trivially guessable and one needs to be very cautious when exposing them to the outside world.
If you encounter some URL like https://fancy.page/users/15 chances are that the 15 is a numeric ID and 1 to 14 also exist. And the lower numbers tend to be admin accounts as they are usually created first. This might be used by an attacker to extract data or maybe gain access to something internal. One could argue that using UUIDs only hides a security hole in this case but thats better than nothing I guess.
I read that point about Discord differently:
One of the often stated advantages of blockchain technology lies in the ability to build decentralized and censorship-proof social platforms. And yet there doesn't seem to be such a platform, people still use Discord.
That sounds like a horrible "might makes right" scenario. If everybody just hires their own goons then the actual enforcement lies in who has more guns/people to enforce whatever they want, not in magical internet points.
It's not necessarily recommended to mix stable and testing but it mostly works fine in my experience. I'd guess Gentoo gets around quite a few problems as everything is compiled from source. So updating a single libary would cause a rebuild of everything that depends on it.
Gentoo also has the concept of "Slots", so you could have multiple versions of the same libary installed and packages will choose their version to build against accordingly.
Yeah, and even if they can't sell collected data because we all agreed to just put them on a blockchain aggregates and whatnot will still be valuable assets.
This isn't an issue that can be solved by technology. It will need regulation/laws and I don't see that happening.
But if you encrypt it so nobody else can read it then the big bad companies of evil will still need to collect your data individually - which brings us back to the initial point, but now with a blockchain for some reason
Wouldn't that be just as bad (if not worse) than the current situation? Those huge corporations could just read everything from the blockchain. At least in the current situation companies need to provide some sort of service to get to your data.
> Auto-completion is no doubt a large part of what's enabled your AbstractBeanFactoryProviderImpl to get those 33 methods in the first place. Which is a big part of my point, autocompletion shapes the way you think about code, shapes how you write code.
Sure, but that doesn't necessarily make it better or worse. People have written horrible code without auto completion, just like they have written horrible code with auto completion. I'm not convinced that you just magically get better at thinking by making your life harder and typing more for no real reason.
> There are also a lot of examples of functions that, by name alone, do not do what they seem to do. That shouldn't be, you might say. But even in the face of that objection, they do exist. It would be very easy to jump to the conclusion that for example "Boolean Boolean.getBoolean(String)" parsed the string and returned its boolean equivalent.
And not having auto complete doesn't help with that at all. Auto complete MIGHT also include commentary for the function and explain what it does (if that commentary exists in the first place) and at least help with the issue.
I know, I learned ancient greek in school, the history and writing was a large part of that. Most (I'd guess > 95%) of the Greeks weren't able to recite the Illiad if I remember that correctly, oral tradition or not. Even the best educated of them wouldn't really have been able to do so. They were familiar with the content, of course, just like a lot of people in what we consider the West are familiar with what the bible is about.
But I'd be happy to be proven wrong about that, school was a long time ago :)
But how does memorizing all 33 methods of your AbstractBeanFactoryProviderImpl enrich anything?
Learning to play an instrument is enriching because you start to understand the logic/inner workings behind the music you listen to. You need the same skill for programming, sure, but I don't see how autocomplete would replace that.
> Nobody today can memorize an epic like the Illiad today like people routinely would in Socrates' day. It a bit impressive if you can reproduce a 3 minute song text from memory. The Illiad often took days to recite.
AFAIK this isn't something that was very common back then. Reciting the Illiad was not a hobby but more like a paid profession. People paid for this precisely because reciting something for a few evenings from memory takes a lot of skill/training and most simply couldn't do it. Same as today.
NFTs stop making sense as soon as anything they are used for doesn't involve the blockchain. Ownership of an NFT that points to some fancy Team Fortress 2 hat means absolutely nothing if Valve decides that it doesn't.
I 100% agree and I kind of wonder why this doesn't seem to be a problem with similar repositories like maven. That doesn't seem to hit HN every 1-2 weeks with a new security flaw/compromised package so they seem to be doing something right, whatever that may be.
Maybe this is arguing semantics but unless you run something like Gentoo you will most likely get the linux kernel as a binary blob contained in a package your distribution provides. There isn't really any guarantee that this will actually contain untampered linux kernel sources (and in case of something like RHEL it most likely doesn't because of backports) unless you audit it, which most people won't do (and maybe can't do). So, in princpile at least, this isn't really that much better than the node_modules situation.
Security and trust are hard issues and piling on 100s of random js dependencies sure doesn't help but you either build everything yourself or you need to trust somebody at some point.
Webpack sure has problems (for example speed) but most of the more niche things that people do aren't actually supported by it but implemented through the plugin system, at which point any category of niche/sane kind of flies out of the window. If you enable people to do weird things people will do weird and maybe unwise things.
The best solution might be to take notes of how people tend to develop js stuff nowadays, scrap javascript completely and use something completely new that doesn't have the issues of javascript. But that seems rather unrealistic at this point.
I'm not trying to argue that it is harder, just different in some ways and ignoring that for the sake of "javascript bad" isn' going to change the point that there are challenges involved. Nevertheless I understand your pint a lot better now, thanks for the explanation.
I think we are both on the same page that the JS ecosystem overall is not in a good shape. But, you know, maybe THIS wave of new shiny tools is finally solving the issues once and for all (not holding my breath though...)
> There is no problem JS transpilers+bundlers tackled that earlier compiler writers had not tackled, better, before.
I'm not sure what I am supposed to do with that statement/answer? It's obviously very easy to just assume that every js developer must be an idiot but that is hardly a fruitful discussion to have.
> What does "plaintext source code" or "over the wire" do to distinguish this from "compiling a binary targeting a minimum supported ABI"? Bundled JavaScript doesn't even have to deal with dynamic linking!
Correct me if I'm wrong on that but it doesn't really matter if something is written in Go, Rust 2015, Rust 2018, Rust 2021, Zig, D or whatever else comes to mind, assuming static linking of course. I can compile it, I can ship it and the binary will work. I can't just ship typescript out, browsers don't understand it. I can't just ship modern js out as I have no idea if the users browser understands the code.
Bundled javascript doesn't have to deal with dynamic linking because it is, in essence, static linking. The whole dynamic linking thing was sort of tried with CDNs shipping js libraries, didn't really work out all that well in practice, relying on some different service to be available for your dependencies is only a good idea until that service has downtime.
Sadly it's a lot more than old IE versions, there are a lot of mobile devices with surprisingly old/buggy browsers around.
Of course this is highly dependent on the target audience but at my last job we did some runtime feature detection (basic stuff like arrow functions, let/const...) and shipped a modern build or a legacy build. And something like 10% of users got the legacy build, most of them on mobile browsers.
Most languages also don't really have to worry about shipping dozens of plaintext source code files over the wire that then might get executed in an environment you have no control over that doesn't actually support the code you wrote (There are still people running old IE versions and loosing 1% of customers might be really costly at scale). I'm not saying that the current ecosystem isn't an overly complex mess but it does actually solve some problems.
"use subdirectories" is probably the most handwavey answer possible, aside from maybe "just put it somewhere, lol". I feel like the standard could provide some sort of guidance on how to name folders or something.
But how does the NFT actually help with that? Couldn't developers/companies just create copies of that item/asset and sell them as often as they want to?
If they want to sell assets/items exactly once nothing is stopping them from doing so right now, they are the only ones who can actually enforce that anyways.
Of course, but they can't just copy&paste their favorite files from the linux kernel sources and call it FancyOs without releasing the sources to that.
I think you got my point, I don't really see the benefit in arguing semantics.
Sorry, that might have been a bad choice of words on my part (not a native speaker). I agree that this process would be simple and easy in an ideal world but we can't reasonably expect every developer to think about price structures for their small OSS projects. So this will most likely involve at least some sort of talking between both parties.
Ultimately the company plans to make mony off of the OSS project, surely those two hours won't make the whole business case invalid.