Almost impossible, it depends on how fast they're being generated and the precision of the timestamp. The real problem is two years later when someone finds and removes that usleep(10000); /* sleep 10 µs */ that was the hard speed brake needed for the UUID generator, and suddenly duplicate IDs start showing up a few times per day or something similar.
I keep telling the dev teams I'm on that with enough data points, all those random numbers will (probably) eventually collide, and *then* we'll see how robust their software really is. At least your database flagged it, and hopefully nothing major exploded.
And yet, plenty of experienced devs, including team leads and CIOs, are convinced it's impossible. As in, they absolutely don't write code to deal with the condition. So a bad RNG can randomly destroy the system far sooner than expected at any time, and it won't be noticed, caught, re-genned, or anything, with concurrent corruption being entirely possible. They're fine with it. I feel like these are the same guys who don't check to see if malloc() succeeds.
I like to ask them, "If it's impossible, you're using too many bits, right?". I haven't talked any of them into hedging with a brownian motion detector, or a lava lamp or something for better randomness yet, but I'm still trying.
I really hate it when the recommended install method is curl-ing some script directly into a shell, often as root. Especially since it's pretty well known that the remote end can tell whether it's going to a script or a file.
GoDaddy proved themselves corrupt forever ago, grabbing domains their customers didn't pay for in time and then auctioning them back to those customers for massive markups. There's a litany of terrible things they've done.
My main domain is still with nic.ddn.mil / rs.internic.net … i.e the travesty of itself today, networksolutions, which once had the ethics to only give one domain name to each physical site so as to make sure future generations could have them. That fled the moment some pharm company attempted to buy about 90 domains at one and the greed set in. But the same process they failed to improved for a decade or two after getting an income stream is still considered more reliable that GoDaddy.
GoDaddy is corrupt, the joke everyone already knew who was in the know.
It puts the infrastructure in place to do all of those things if a future(?), authoritarian regime wants to.
* It also reveals that visitors to any site are children, compromising their privacy and opening them up to targeted advertising
* The data will undoubtedly be added to the accumulated, traded databases so many services use
* The bill makes onerous demands of developers to consider other items that may suggest the user is actually in a different age bracket, like doing websearches for "toys" (child) or "toys" (adult) - which works what percentage of the time, exactly?
* And it's totally ineffective, since kids can look at porn anywhere they want, or internationally, regards of useless bill like this
The most egregious part of this bill is that:
* It legislates that if kids connect to a website, that website can query their age brackets (an "age signal"). This means their approximate age is revealed for kids-specific advertising, manipulation, or even sold to a pedophile group.
A DEVELOPER SHALL REQUEST AN AGE SIGNAL WITH RESPECT TO A PARTICULAR USER FROM AN OPERATING SYSTEM PROVIDER OR A COVERED APPLICATION STORE WHEN THE DEVELOPER'S APPLICATION IS DOWNLOADED AND LAUNCHED.
Basically SB 26-051 creates a mechanism that can be used to harvest the data that certain users are kids and then sell that data to anyone who will pay for it.
Data like this is traded internationally, which makes it tragic that elected lawmakers would waste time pushing a bill whose only mid-term effect would be making Colorado less attractive to developers and software companies.
The irony is that normally your kids would have been protected, by standard practices, from having their age exposed. This bill reverses that, putting your children at more risk.
The bill also would force many devices to provide age bracket data that are surprising to most people, because this part:
"DEVICE" MEANS ANY GENERAL-PURPOSE COMPUTING DEVICE THAT CAN ACCESS A COVERED APPLICATION STORE OR DOWNLOAD AN APPLICATION.
... means anything with Internet access and storage. This includes smart televisions, thermostats, tablets, smartphones, smart watches, some fitness tracking devices, some smart toilets, and so on, all potentially reporting your activity on demand, even if that back-end service has nothing to do with porn.
The bill is also poorly structured. Clearly it's intended to focus on services like app stores (Android, Apple), but by attempting to integrate support for this into operating systems, makes it available to hostile actors for any purpose worldwide. Further, it requires developers to guess whether other available information on a user might mean they're really in a different age bracket, exposing them to fines of $2500 to $7500 per minor "affected" (note: "affected" is not defined in the bill). The exemptions give blanket protection to developers working on for-internal-use software, but give no exemptions to recreational programmers. non-profit personal software, university projects, and so on, casting a chilling effect across software engineering generally.
Lastly, the bill is ineffective. Most of the web runs on Linux, a coöperative international effort, nominally controlled by one man in Finland. There is no chance of this bill's mechanism being implemented in this context. Nor will other developers be especially interested in rewriting software for this Colorado-specific bill. Further, the kids supposedly being protected from all the Colorado native porn sites would just web-browse to nearly any porn site and be outside of Colorado anyway, if not outside the US entirely.
These sponsors aren't alone. Most elected lawmakers are equally bad at technology and protecting democracy from the threats that come from chipping away at privacy protection. Bills like this appear in other states all the time, despite being toothless, easily circumvented by kids (who trivially circumvent even face photo hurdles), or radically compromising the privacy of adults (like this one).
There's also the long game, where these sometimes Democrat-led bills in various states could eventually see a much deeper-reaching federal one, where, instead of a "age signal", the user's computer must send an "ID signal", allowing all personal interactions with the Internet to be tracked, analyzed for political and other biases, and used by backbone firewalls to control exactly what people are allowed to read. Very handy for a dictator who might want to block off "fake news".
This is only a hypothesis, but one has to wonder whether sponsors to such bills even care if the bills work or pass, since either way they still get to claim they Protected the Children! even though the bills themselves violate privacy for everyone, often cause websites about breast cancer to be censored, or pave the way for authoritarian control - something this one stands out for. The only thing really surprising is that this bill wasn't sponsored by MAGA Republicans deliberately to add another paving stone to the road to national censorship.
I urge everyone to get in touch with other Colorado representatives to call for a fight against this travesty of a bill. Further, I would excoriate the two sponsors by email and phone, and tell them now that you will not reward this sort of juvenile lawmaking with your vote. Lastly, tell other people about how Matt and Amy plan to strip away their privacy in a way that puts children more at risk than doing nothing.
While XML was imperfect from overcomplication, JSON is imperfect by falling short of even basic database use, and somehow despite its alleged simplicity it manages to be unstandardized almost as badly as Markdown. JSON and YAML both fail to have comments that survive processing, something it's easy to regret since XML does have comments that appeared in the parsed objects.
A saner subset of XML, possibly run through some over-caffeinated developers to lighten its redundant syntactic feeling, would have given us something FAR better than JSON's failure and YAML's gratuitously hypercomplicated syntax.
XDG doesn't handle complex environments, especially not heterogeneous computing environments. Something long the core strength of Unix is acknowledged by XDG and then left utterly unaddressed. Without this, the "standard" is as much an impediment as an aid.
It's amusing that modetc goes through all this effort to twist dotfiles into the XDG half-solution, and here I am using symlinks through /dev/shm/xdg/* to warp XDG into sort-of working in an actual heterogeneous environment.
Because XDG by itself is a failure beyond trivial cases.
A while ago, I just wrote a filter to be able to paste markdown into a <name>.smd file, and an Apache filter to autoprocess them much like any other filter (and a <named>.smd.meta for title info and some other metadata).
This makes it super easy to write something cool on Reddit or whatever, then just paste the markdown into an index.smd file in a new directory (named meaningfully) and poof it's in a webpage.
The core of all of it is a /var/www/cgi-bin/markdown-to-html program centered on:
# This works, with setup in /etc/apache2/conf-enabled/mod-ext_filter-adds.conf
AddType text/markdown .md
AddType text/markdown .smd
AddOutputFilter markdown-to-html md
AddOutputFilter markdown-to-shtml;INCLUDES smd
Much easier to just edit markdown (index.smd usually) and reload than reconvert, and that filter above lets you include arbitrary HTML too, critical to deal with markdown numerous weaknesses.
I just hate that (1) you can't nest anything into a table (2) it's different everywhere.
Restructured Text is much more capable, and yet here we are, still using Markdown.
My markdown pages often also have HTML in them, I mainly use Markdown so if I decide some overlong thing I wrote on Reddit actually doesn't suck, I can copy-paste it into a webpage, and my web-server's .smd handler does the convertion. Lowest common denominator. :(
Don't put suffixes on command names. Don't. It's a DOS thing that has no meaning in Unix. It confuses users. It breaks hiding implementation details. It encourages users to do the wrong thing. It makes changing what language a script's in have a ripple effect of breakage across everything else that uses it.
