auvrw
Isn't that so the spirit of the times when working with LLMs? If one asks for a Prisma schema or something else out of GipPTy meant to be fed into a traditional parser, we're up the the whims of the attention blocks and layers to write out something that doesn't become a parse error. One can turn the temperature down, fine-tune, or self-host a model but does that guarantee the syntax will be correct (much less the semantics)?
i'm guessing that writing dyson in Nim is a tacit acknowledgement of that: if this were something geared toward production ecosystems, it would be in golang like kubernetes? although there is the helm luafication, so perhaps dyson is part of a fringe of non-golang k8s auxilliaries.
another way to implement this is with a 'static CMS' where there are still static pages except built into a situated deploy. the 'cultish' (cultic? anyway) aspect of k8s appears to be to phrase all the things in terms of k8s constructs rather than using k8s constructs as a foundation and abstracting out.
i learned about 'rollout' from the CI portion of this post, although initial attempts to search for a comprehensible description of it fail.
in particular, and i've read that writing kernels isn't feasible in Go. it appears not to be an issue of performance. something about the runtime prevents writing kernels altogether.
like the linked article says
https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repl...
rust has a lot of features (generics, etc.) aside and apart from the memory management strategy.
i'm also unaware of a procedural language that has the feature stability of C or Go as well as the ability to write kernels or embedded code with the memory safety of rust.
currently wondering how easy it'd be to tack rust's memory model onto another language, alef in particular.
DSLs, otoh, are in short supply. while awk or plain sed are great for shell programming, this is the only (open source) DSL i'm aware of targeting certain types of NLP-esque "munging". this space is mostly full of statistical approaches, which, while conceptually pure, don't allow the kind of flexibility that would be useful in many applications.
i wonder if, eventually, the DSL portion of TXR could be sheared off (possibly via metacircular evaluation of the TXR lisp?) into something that's portable across lisps or at least to semi-standardized scheme implementations?
http://doc.cat-v.org/plan_9/4th_edition/papers/names
note that the filesystem interface isn't totally durable across all operations: a syscall is still necessary to create processes, for instance. cp /proc/... doesn't do what one might think it does.
http://doc.cat-v.org/plan_9/4th_edition/papers/9
i appreciate that the original article similarly acknowledges that lisp is an "all the things (except for some things)" solution in the Single address space section. synchronization libraries (and perhaps other libs as well?) in C-based OSs need to drop into assembly to get at test-and-set kinds of operations. addressing these special cases one-by-one is something that'll need to be ramified in source in order to get any real insight, although (perhaps just from the inertia of familiarizing with the original bell labs warp) it's difficult to imagine the kernel as a "all the things, seriously everything" abstraction away from the machine.
----
overall, the original article and discussion here was a bright spot in my day. it gives me hope that there's some actual thought and discussion about how to evolve operating systems intended for commodity hardware, not just generalized, "yea, that's something we could do," one-offs. i'm not as familiar with the xerox heritage mentioned elsewhere in the comments, and the view that, in some sense, linguistic abstraction might cover OSs is something to think about.
i've heard the smalltalkers catch some flak about not actually writing an os because there was (apparently) the equivalent of exec(), no fork()
http://bitsavers.org/pdf/xerox/alto/memos_1975/Alto_Operatin...
this criticism of the alto OS could be due to cognitive bias as much as anything else. the concept of processes is by now deeply ingrained in the way we conceptualize operating systems. so i have to ask: is leading with eschewing processes a clean-sheet rethink, informed by history's mistakes as well as its successes, or is limiting the number of OS primitives at the expense of less-rich interfaces actually a desirable tradeoff?
like, although everything i've heard about multics in particular seems well thought-out, thomson and ritchie were doing something substantially different by opting for bytestreams as much of the interface rather than making strict decisions about arities and so on. every rule system makes is bound to be a rule a user will eventually want to break. i suppose the operating system's main job is to safely lift off of the hardware, not to impose further unnecessary artifice (of which hierarchical file systems AKA namespaces could be viewed as one) on the user. adding further icing onto this core objective is so much the better, so long as it's possible to scrape away and redecorate.
the canonical text here is Federer, although it's supposedly a tome. Krantz's _the geometry of domains in space_ appears more approachable.
...
also, note that these topics aren't totally separable.
https://medium.com/@tonistiigi/build-secrets-and-ssh-forward...
the link you've supplied regards ssh access when running docker images, not when building them.
... i did notice that for lots of downloads, it is somewhat slower, or perhaps more prone to lag, than authentication from inside the running image.
misc. Forrest Mims notebooks, the Python Tutorial, Practical C Programming
first chapter of Sound and the Fury, snippets of Naked Lunch, wide swaths of Ulysses
The Universe in a Nutshell, French's Special Relativity
The Gamma Function, a graph theory text whose name i don't remember, baby Rudin
Brain Structure and Its Origins, The Form Within
> Obviously, this is a project for an advanced electronic hobbyist and computer enthusiast.
is somewhat tongue-in-cheek: this could be the thing to get a kid who's already soldered together a bunch of (less expensive) analog hobby kits .. or the adult who's into that sort of thing.
it's pretty much the same thing as building model cars, airplanes, etc. although it doesn't teach you exactly how the thing works, the perceptual task of doing the soldering and checking out the traces gives some idea of how things piece together.
as far as vintage electronics go, IBM PCs (probably?) aren't that difficult to find for those who're essentially interested in abstracting away from the hardware.
here's my issue with the article text: it describes
I came to the Graide Network and immediately started breaking our legacy app into microservices.
here's where some of my experience partially aligns with the article's complaints
Investors are guilty of pushing it on us
here's where the author begins upon the path to enlightenment
we can build more with less.. however, this article appears to be advocating a style of programming that i'd be more apt to call Test Driven Development than Literate Programming:
it demonstrates a way to use naming conventions and mocks/stubs to describe a program, not a way to use natural language, math notation, etc. to describe a program.
for JS (the lang in the article), proxyquire+simple-mock is a non-emacs-centric way to do this. toss in tape or some other testing library, and you've got some amount of natural language documentation as well.
this is more what i'd consider literate programming in JS land
https://marionettejs.com/annotated-src/backbone.marionette.h...
... by way of disclaimer, i ought to say that, for all i know, i'm grossly misinformed as to the meaning of TDD as compared to Literate Programming
woop, woop!
the design where the display is _least_ fragile part of the laptop is brilliant: wins over removing extra ounces or millimeters. i wish more laptops were built this way and suspect the only reason they aren't is because it doesn't look as "hi-tech" as some of lenovo's other laptops.
.. what's going to be neat to see is how that "essentially the same thing" changes over time.
deepstreamhub.com is another neat SaaS that's worth looking into for some cases that Firebase might not handle as well ... there are probably yet other SaaS products that cover other specifics and will be still more in the future..
.. obvious mention re. SaaS products is that they could evaporate at any time. warranty void where prohibited. all states except ... idk, AK, for some reason.
if time-tracking somehow solves the bare moneys/hour problem, other, perhaps worse, conditions could surface (thinking of what it's like to work in an online shop warehouse here, in particular, where time-tracking is .. not a complete "solution.")
traditionally, afaik, unionization is the way out of situations where a great number of workers are disadvantaged by some policy set by a few people in the industry.
this is a social [(science)?] problem, not a technological one.
the correspondence with neuroanatomy is impressive. i s'p, at that level (and i mean, likely even at the proteomic level for those that're particularly studied in that area), it could be easier to have results that can guide intuition. b/c that'd surely the useful thing about these kind of results, i imagine, off the cuff, to most people in the natural sciences: providing hints for further research on causal mechanisms and perhaps a reasonably plausible story or "hypothesis" to be fancy (like ketchup) about it
(disclaimer: i dr)
https://github.com/ransomw/botiful-soup/blob/master/mibot/sr...
as i recall, there's a lot of neato REPL-y graphvis to try in
https://github.com/ransomw/botiful-soup/tree/master/mibot/de...
----
while i'm here, let me mention: Gärdenfors books like "Geometry of Meaning" are hearty food for thought about natural language semantics
... i suppose this project is locked into G-standard C++ and with lots of good reasons (e.g. toolchain). although i'm an anti-C++ person, i suppose the sorts of tools available internal to Alphabet make it much more manageable.
anyway, for an example of the original premise: i'm slowly learning some things about plan 9 C via 9front.. there are some departures from ANSI C, including additional features like (completely undocumented, except for the relatively compact source) operator overloading. equally important for the type of person that finds C++ too busy, some features (e.g. certain preprocessor features) are removed.
also, Horowitz and Hill, to echo what i suppose is mentioned elsewhere.
texts: carothers for reading like a novel, rudin for taking apart like a car engine...
... or, drop all your classes and learn to formulate everything in the terms of measure theory from the beginning. halmos's texts on any (mathematical) subject are almost always well balanced ...
... o! that reminds me. also, there's this thing called "functional analysis" that'll be worth looking into after basic topology is well-cemented.
can be replaced by
> with frequent upgrades, errors are sparse blips on the Debian testing release
-
standard line: if you're considering Debian for the desktop and want a reasonable mix of stability as well as recent updates,
testing recommended over stable.
... on "evidence-based" (cf. CDC) v heuristic reasoning: certain aftershaves and similar make me gag.
knowing it's because of petrol is just the evidence i need to become self-righteous about it :D
https://github.com/ransomw/exercises/tree/master/lleaves/plu...
... only gripe with this article is the couple of "... and/or C++" clauses: i personally hope to be forgiven for forsaking C++ for new projects, because it is not the 1970's anymore, and i suppose there are alternatives for almost every use case as well as externs for plain-C interop with existing C++ libs.
it's more like C+{100} so many are the additional feature-ughs.
> I had also heard something years earlier about autistic people having issues with certain types of clothing similar to my own.
similar in what way? from https://www.autismspeaks.org/blog/2017/06/05/autism-and-resi...
> We know that many people on the autism spectrum prefer relatively snug-fitting clothing that covers their arms and legs.
...i did not know that. however, i did know that incredibly fashionable people prefer relatively snug-fitting clothing that covers their arms and legs, thank you.
i did one "field of dreams" project using a stack that i was mostly familiar with already and several "effort" project to learn and demonstrate skills in a different language/stack (Clojure).
totally agree that once the interview screens started, that side-project time got scaled back to vanishing. however, i'm really thankful that i had enough time to do the side project milestone as well as the interview proper, because i wound up finding a role developing in Clojure. i don't think that would've been possible had i not invested the time in side projects before starting in on interviews.
debt can be viewed as another word for "relationship."
and it's cool in some ways, yet in other ways kind of a shame: debt from the United States is, to some degree, buying into the military-industrial complex. valuing China's money is, in part, condescending to a rather selective perspective on human rights. hopefully the guanxi flows to the best in each rather than the worst.
i don't pretend to understand the international economy. however, with the sort of logistics enabled by modern communications technology, i suspect that it's a lot more feasible to completely pack one large barge with a variety of goods than it used to be, making for lower-cost shipping than one might expect.
https://github.com/ransomw/dotfiles/blob/master/tmux.conf
along with a rant about what terminal multiplexers are in the first place
https://github.com/ransomw/dotfiles#tmux
... both are wip, suggestions welcome
i noticed the updated name when running `mutt -h` one day and was pleased to find this page
with good documentation along with an active github repository and apparently welcoming community. i think there's even a Twitter account for "keeping up with the times."
yes. this is important, even if only for testing.
my [semi]current test setup for jssip resorts to webdriver testing because the WebRTC is not completely decoupled
https://github.com/ransomw/simp-phone/blob/master/test/clien... https://github.com/ransomw/simp-phone/blob/master/test/clien...
i guess these updates would allow me to test call functionality completely within the node runtime without scrounging around for WebRTC mocks?