knome

If you enjoy linotype machines, I'll suggest you watch 'Farewell ETAOIN SHRDLU', a documentary on the last night the New York Times ran its hot press system

Looking both ways is undone if drivers are speeding, not bothering to stop at stop signs and being generally unpredictable and dangerous.

Blaming pedestrians for getting run over by speeders that are too impatient to drive at safe speeds in residential areas is a ludicrous opinion to take.

if you train them on randomized names, they'll also suggest them.

better to not, I think.

>The people / companies involved made it really clear that they don't want to be making the rules

They may not want to make the rules, but they do want the rules. They just don't want the blame. Otherwise they would just, not have the rules around who they'll work with. They would just work with anyone and tell anyone that complains about it to complain to the government, that it's company policy to work with any legal company.

DNS doesn't stop to check if you're okay to have a name. Water company and electric don't refuse to hook up your building because they don't like your business.

They have chosen to become content arbitrators. It was not foist upon them.

monads were certainly a clever fix for the difficulties otherwise caused by passing around the world as a value.

I might argue that laziness makes haskell something different than purely applicative.

It's not just pure values being passed around. It's a language built atop suspended self-caching invocable thunks getting knotted up and then firing off in chain reaction.

    main = do
      let
        hello = foo world
        world = bar hello
      putStrLn $ show hello
      putStrLn $ show world
     where
       foo v = [v]
       bar v = length v

side effects are quite the thorn in this theories side. hard to describe message passing in purely applicative terms.

that would probably depend on how much power it takes to send the messages, how much actual usable bandwidth you could manage over the distances involved, and how much data you want to send.

if it takes a large amount of energy to send the data, we probably wouldn't want to run the equipment all the time. strong pulses would let the equipment cool down or recharge capacitor banks or whatever during downtime.

interstellar dust and other debris floating through space could cause interference, not to mention radiation from everything else around us, and our own sun shining right next to our little laser.

might want to move the laser out onto pluto or something to avoid having it right up against the sun.

there's a lot of interesting problems just in the networking.

if it took four years for a message to cross the void from where you are to the recipient, you certainly wouldn't want to wait a full eight years to see they didn't send a receipt message and only then retransmit.

eight years is some awful latency.

you'd probably want to send each message at something like a fibonacci over the months. so, gaps of (1, 1, 2, 3, 5, 8, etc) would mean sending the message on months (1, 2, 4, 7, 12, 20, 33, etc) until you got a confirmation message that they had received it. they would similarly want to send confirmations in the same sort of pattern until they stopped receiving copies of that message.

spreading the resends out over time would ensure not all of your bandwidth was going to retransmissions. you'd want that higher number of initial transmissions in hopes that enough of the message makes it across the void that they would have started sending receipts reasonably close to the four years the initial message would take to get there.

if you had the equivalent of a galactic fido-net system, it could be decades and lifetimes between messages sent to distant stars and messages sent back.

>Do we say "UK developers new method for ..." or "Researchers at Cambridge"

these would be completely normal headlines, in my experience.

It is considered incorrect, but it also sounds nice and forms a part of a growing number of terms being pluralized using -i, radiating out from cacti, it seems. I expect this trend will continue.

Payment processors banning companies from using them for anything other than illegal use or fraud issues seems like pretty egregious overreach to me.

They shouldn't be able to leverage their nigh monopoly on modern payment processing to choose winners and losers in the marketplace.

They are using pornography as a wedge issue to establish that they get to dictate what companies are allowed to exist in the modern distributed market.

It would be entirely reasonable to legally require them to act blindly towards retailers, with restrictions needing to be based on universally applied financial criteria.

Card payments have become inseparable from modern life.

Regulate them as a financial utility. The electric company or water company can't refuse to hook up a business just because the owner doesn't like that business.

>The modern workforce shouldn't be flinging copies to each other. A copy is outdated the moment it is downloaded. A copy has no protection against illicit reading. A copy can never be revoked.

A copy is always available. A copy is naturally a versioned checkpoint. Having a single author regularly publish an authoritative copy means people always receive a version that is ready and that has been deliberately published rather than something a half dozen authors are in the middle of live editing. It means you can compare versions to see changes.

>And git! Don't get me started on git! The best minds of a generation stuck in a paradigm of downloading files to their local machine, making changes, then ~emailing~ /git pushing/ them up to be approved? Madness!

There is no central server in git. It's often used that way, yes, but git itself is a wholly decentralized database that propagates changes via diffs, with each person controlling what they do or do not allow into their personal graph node. Approvals are important to keep mistakes, errors and general slop out. A request to pull indicating readiness, and code reviews to guarantee it. Working in files is reasonable, as these are the assets that the compilers will be working with. Forcing compilers to download each individual compilation unit from a tagged central database because you're ideologically opposed to the concept of files is more than a bit ridiculous.

The idea of exclusively collaborating via editing using online editors or webdav shards or whatever with no local copies probably sounds great if you don't care about being able to work when there's no network, or using custom tooling, or doing anything that isn't custom built into your IDE, or to build and test without requiring an entire architecture of overly complex per-dev environments constantly being remotely rebuilt on some overburdened and expensive centralized platform.

Thin clients increase control at the expense of user experience.

It sounds awful to me.

wikipedia still being around after all this time and still maintaining links to just download the entire thing and having no ads makes whatever they're doing good to me, ha.

it varied. with the earlier models, generally more, trying to see if some apparition of mechanical understanding would eventually click into place.

IIRC, none of the gpt3 models did well with forth-like syntax. gpt4 generally did okay with it but could still get itself confused. claude4opus doesn't seem to have any trouble with it at all, and is happy to pick up the structures contextually, without explicit documentation of any sort.

another of my languages uses some parse transforming 'syntactic operators' that earlier models could never quite fully 'get', even with explanation. likely because at least one of them has no similar operator in popular languages. claude4opus, however, seems to infer them decently enough, and a single transform example is sufficient for it to generalize that understanding to the rest of the code it sees.

so far, claude has proved to be quite an impressive set of weights.

don't plan on it staying that way. I used to toss wads of my own forth-like language into LLMs to see what kinds of horrible failure modes the latest model would have in parsing and generating such code.

at first they were hilariously bad, then just bad, then kind of okay, and now anthropic's claude4opus reads and writes it just fine.

I wrote a tar parser long ago while playing at parsing various formats and filesystems.

The only thing I really remember about the format is the thing stores sizes formatted as octal in ascii strings.

I don't think it particularly moral to start heading down a path wherein we are essentially aiming to create enslaved cloned vat brains. I know that's not what they have, and that they're nowhere near that, but if they succeed in these early stages, more and more complex systems will follow in time. I don't think it a particularly healthy direction to explore.

>Maybe our first AGI is just a Petri dish brain with a half-decent python API.

https://www.oddee.com/australian-company-launches-worlds-fir...

the entire idea feels rather immoral to me, but it does exist.

ghoti is a ridiculous example. it takes its components entirely out of context. 'gh' as 'f' only occurs at the end of a syllable, 'ti' as 'sh' only exists as part of '-tion' where the pronunciation slurred over time. Pretending it says anything about the nature of the English language outside of English being a complex merging of various other languages that has evolved with time is silly.

Squashing "danube steamboat shipping company electric services main maintenance building subordinate officials association" into a single word vs leaving it spaced out is kind of irrelevant. It's like getting excited over PascalCase vs snake_case.

I don't often need gdb, but I appreciate the emacs mode that wraps it every time.

yeah, traditionally 'generated code' is really just 'decompressed code'. it's got some source of information that's either brought in or crafted to be easily read and modified by people, and a transformer to expand it in a regular way that means, assuming the transformer isn't flawed, the code will always be correct.

if there was an `if( randomly() ){ emit("error"); }` in there, we'd be right back to reviewing it and probably wouldn't bother with it in the first place. besides which, any work to the transformer itself necessitates review even for generated code, making sure that the output is actually what you expect it to be.

the idea that you shouldn't care what's in a function because your possibly-insufficient-over-the-interface tests passed is kind of insane.

I wonder how much of that is on the modal itself. If we instead popped up an alert that said "blocked an attempt to talk to your local devices, since this is generally a dangerous thing for websites to do. <dismiss>. to change this for this site, go to settings/site-security", making approval a more annoying multi-click deliberate affair, and defaulting the knee-jerk single-click dismissal to the safer option of refusal.

I think it's reasonable to assume the poster meant "dotnet" and that you're responding to a typo

>(meaning at least 10x larger than CMOS transistors)

at petahertz (10^15) speeds, you could sacrifice a lot of space for larger components, and still come out on top vs gigahertz speeds (10^9) by doing more work but a hell of a lot faster, no?

if you can build a chip that's a million times faster, you can sacrifice 3/4 of that speed to doing more work with fewer components and still be 250,000x faster.

I was playing around, and inspected the boid count control to see if I might manually update it and see what unreasonably large and small populations look like. I saw the connected callback triggered updateProperty. Running updateProperty("boidCount", 10) in the console yielded a field with 10 boids, as expected, but apparently it doesn't update something else the natural code would, as as soon as two of the boids collided, a humongous explosion of boids occurred, like a firework.

You can and should put as many as you can there

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

If instead of validating that someone has sent you a phone number in one spot and then passing along a string, you can as easily have a function construct an UncheckedPhoneNumber. You can choose to only construct VerifiedPhoneNumbers if the user has gone through a code check. Both would allow you to pluck a PhoneNumber out of them for where you need to have generic calling code.

You can use this sort of pattern to encode anything into the type system. Takes a little more upfront typing than all of those being strings, but your program will be sure of what it actually has at every point. It's pretty nice.

for glibc and linux, fork just calls clone. as does posix_spawn, using the flag CLONE_VFORK.

if they're going to be arbitrarily against env vars, like CURL_HOME, CURL_SSL_BACKEND, CURL_CA_BUNDLE, or the other dozen-ish variables curl already checks, an option in could .curlrc seem reasonable.

of course, having a CURL_ALLOW_ONION would allow the oniux program to set it, which would very easy and straight forward for both sides.

alternately, oniux could itself run a proxy and set the appropriate proxying environment variable, like HTTPS_PROXY. This would have the advantage of curl not having to do anything, but would add a rather ugly bit of complication to oniux.

seeing as the ability to run and inform curl of a proxy means oniux can already bypass the onion blocking with an envvar, adding one specifically to do that is convenient for callers, and does not expose the user to parent programs controlling onion exposure any more than it already does.

at best you could argue that requiring a full proxy makes it slightly harder for naive users to accidentally expose themselves since it would raise the bar for exposure from what curl knows, being the env var, to what curl has, in the form of an available proxy endpoint, but this isn't really a great excuse not to implement the CURL_ALLOW_ONION env var.

it's nice that curl is helpful for blocking by default, but having curl require the user to jump through hoops to unblock onion is a bit much.

sure, but you'd see folks using them to add metadata and extend json in horrible incompatible ways