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.

Quarkdown's page has this:

curl -fsSL https://raw.githubusercontent.com/quarkdown-labs/get-quarkdo... | sudo env "PATH=$PATH" bash

And… yuck. And that ".sh" is kind of annoying all by itself.

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.

Colorado Senate Bill "26-051"

The actual bill and links to its two sponsors Matt Ball and Amy Paschal.

    https://leg.colorado.gov/bills/SB26-051

    https://leg.colorado.gov/legislators/matt-ball

    https://leg.colorado.gov/legislators/amy-paschal

* 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.

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.

Developers Are Stupid - developer.

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.

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. :(

Except:

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.

Don't do it.

* hollerith cards and sundry + printer * printing teletype * dumb (video) terminal * smart (cursor addressable) terminal * images of smart terminals * images of smart terminals with color (businesses resisted color for years) * ... ?

And in the meantime we have an evolution of support for modelling things visually and working with more descriptive protocols - or even function-defining protocols to raise the abstraction chatting with the display server in realtime. In this, "abstracted" means something that can be sent over the network instead of using a local buffer. These are in a less strict order than foregoing...

* text, color plotters, VDST, and all that other old slow stuff * [skipping a bit up through bitmapped greyscale graphics] * bitmapped color graphics * abstracted 2D graphics (-> W and X) * abstracted 3D graphics (OpenGL + GLX) * dynamically client-extendable remote graphics servers (NeWS, mostly 2D) * ... ?

So here I am, waiting for the next stage in these. Hypothesizing that finally we'll get something with 3D abstracted, network graphics (display lists in GLX but accelerated with something like XCB?), where the primary display coördinate space is (x, y, x) instead of (x, y), where the client can push some code to the remote server and raise the abstraction on the fly, finally. Where maybe we'd be able to permission the objects in that space and share it among users live. Where the 2D apps would be inside the 3D space instead of the other way around. Something for the 2000s instead of familiar abilities provided in 1990.

But instead, Wayland. Wayland, which is not backwards compatible with X. Wayland, which is 2D at its heart. Wayland, another 1990 era graphics system with a super thin offering of features for actual end users (not devs) which come at substantial cost in lost X features. Wayland, which resists the one user doing things we've long thought of as normal - in the name of "security".

Wayland is not what I've been waiting for.

Arrogant.

But not as bad as those jerks that use smaller and smaller, progressively lower contrast text as the actual content gets more important. Huge readable repetitive headings, microfiche gray-on-gray for the stuff that mattered.

Going to OpenGL is a nice tactic, since OpenGL doesn't give a flip about screen coördinates anyway.

I miss NeWS - it actually brought a number of great capabilities to a window system - none of which, AFAIK, are offered by Wayland.

While the document itself is pretty good otherwise, this philosophical failing is a problem. It should give examples of COPING with memory exhaustion, instead of just imploding every time. It should also mention using "ulimit -Sd 6000" or something to lower the limit to force the problems to happen (that one happens to work well with vi).

Memory management is mature when programs that should stay running - notably user programs, system daemons, things where simply restarting will lose precious user data or other important internal data - HANDLE exhaustion, clean up any partially allocated objects, then either inform the user or keep writing data out to files (or something) and freeing memory until allocation starts working again. E.g. Vi informs the user without crashing, like it should.

This general philosophy is one that I've seen degrade enormously over recent years, and a trend we should actively fight against. And this trend has been greatly exacerbated by memory overcommit.

For more... interesting network scenarios, it can be helpful to construct some variable, say, $HOSTABI, that includes tokens for both hardware and OS.

$ echo $HOSTABI x86_64-ubu-2204

Which can then be used inside architecture-influenced variables like ARCH, LIBRARY_PATH / LD_LIBRARY_PATH, PATH, as well as inside the user's own installation system (makefiles, etc) used for anything the user compiled. Great for just installing some new hw/sw combo, mount home, cd into "~/src" or equivalent and run "make install", and just get all your own code recompiled and installed for your new architecture.

This is a microcosm of what sysadmins on heterogeneous networks do, mostly for different hardware architectures, although this was a much more common situation in earlier years than more recently where Linux has taken over even more of the corporate/research world. I've found it pretty useful even at home, where I'm using my one home directory across my systems' different installations of Linux with different library requirements (although I should probably sell that SGI Onyx/RE - IRIX not Linux - that Wing Commander III was rendered on).

My home directory is usually populated almost exclusively with dotfiles and some threescore subdirs with 3ish-letter names like doc/ etc/ fun/ (I'm a gamer) git/ iso/ job// lib/ man/ pub/ (packages of my own programs) sbin/ src/ steam/ (yep) tmp/ var/ (notes, logs, etc) vr/ ... and so on.

It seems to work out alright. Contains about half a million subdirs and 4.2 million files. ;-)

Although big companies also have some leeway to steal domains (and the associated email addresses) from small companies and hobbyists, so just trying to keep your email to yourself doesn't solve everything.

Of course, that nearly every domain anyone wants is taken already is also a bane on us caused by a big company - Network Solutions, the privatized descendant of the Internic, as they realized their old rule of one entity / on domain didn't have to be followed, and blithely made their first evil sale of 80-odd domains to some household name drug company that wanted a domain for each common ailment or something. The idea of saving readable domains for future generations went right out the windows once someone waved money under their nose (and they didn't use that money to improve their UX for over a decade), and now virtually all registers are shills for shoving domains you don't need down your throats. Ugh. At least the old Internic had ethics.

Just like Google had the do-no-evil motto - somehow I doubt that's still a thing. Good luck getting a lost email account of them - they didn't give my Google phone number back even though the system still knows it's mine.

A bit off topic at this point, sorry.

Sure it sounds interesting to try a branch of pg with, for example, just the sessions being multithreaded - but then how DOES one forcibly stomp on some session that has grabbed some critical lock without crashing other users' sessions? Killing off a session's thread inside of a MT'ed session handler without putting any other threads at risk would be the first problem (and an admin is likely to use "ps -Lef" to find the thread ID and then "kill"). Many MT programs I see lose their little minds if a thread is killed from outside.

Going too crazy with threads can also cause performance issues, since there is overhead - just less than for processes - around thread creation/switching/etc, and is why thread pools are common. There's a short article about this at:

    https://stackoverflow.com/questions/5961536/what-is-best-a-single-threaded-or-a-multi-threaded-server/5964238#5964238

This is a pretty good page on the options in general, though dated (anyone already know of a newer equivalent to it?):

    http://www.kegel.com/c10k.html

I'm not trying to win an argument or anything here, I'm just highlighting from my and others' experiences that multithreading is a tradeoff not to be made casually. It makes some things faster, especially if not I/O bound, but it also increases dev and debug cost, and reduces the number of developers who can assist. That downside tends to permanent.