This is needlessly pedantic but postgres is not multi threaded, Or at least historically it was not I don't really know if threading is currently being added or if the cloudbased "postgres-buts" have threading. but postgres standard is a pretty good example of the traditional forking unix server, And as someone deeply suspicious of threads in general, just because we could define a shared memory execution modal didn't mean that we should have done it, I think shared memory introduces too many footguns. Sticking with a multi-process model is probably the correct choice for postgress.
Needlessly pedantic because the distinction between multi process with explicit shared memory(shm) vs multi threaded with implicit shared memory probably does not really matter all that much.
It would be nice to have more declarative constraints. The solvespace file format is plain text and it almost feels like you could write it by hand, but that would be a lot of manual record keeping. and you would loose all that imperative goodness. Perhaps you could have an imperative layer(say python or lisp or forth) that outputs the declarative layer(solvespace) and then solvespace renders(picture or stl) the declarative layer.
I think a text input option for Solvespace which was optimize for readability and usability would be _very_ interesting approach, esp. if Solvespace was able to write back out to the same format, and it allowed math/variables/parameters and supported the same in the UI.
but contrails are not made of soot, where I define soot as dark unburned carbon, contrails actual are made of water. There is also a highly likely chance I am being to literal and the word choice of soot was a bit of poetic license on the part of the author.
As a bonus consideration it might be better if they were made of soot, it would be ugly but water vapor is a tremendous greenhouse gas, several times as potent as CO2, soot blocking the sun might have more of a neutral effect, And related, we worked hard to get sulfur out of our fuels but sulfur dioxide turns out to be a negative greenhouse gas, it has a net cooling effect, I am not saying we should deliberately add sulfur back in, the downsides are too great, but it is an interesting bit of irony.
Sure, but water vapor doesn't spontaneously transition to a liquid and accrete onto surfaces - there needs to be a super-saturation of water vapor, and given the temperatures of jet exhaust, that's not trivial to achieve. However, the super-saturation needed for water vapor to deposit onto surfaces as ice is much lower, hence the preference for ice crystal nucleation.
Why does it matter? I mean I guess it did in this case but that is considered a top priority bug and quickly fixed.
I guess my point is the way the internet works is that your traffic goes through a number of unknown and possibly hostile actors on it's way to the final destination. Having a hostile actor presenting a spoofed wifi access point should not affect your security stance in any way. Either the connection works and you have the access you wanted or it does not. If you used secure protocols they are just as secure and if you used insecure protocols they are just as insecure.
Now having said that I will contradict myself, we are used to having our first hop be a high security trusted domain and tend to be a little sloppy there even when it is not. but still in general it does not matter. A secure connection is still a secure connection.
Very cool, I wonder why the service was never updated to work with saturn. No hdd would be my guess. with no hdd games have to be absurdly small to fit in ram.
I will note that as I was reading the saturn specs(I am unfamiliar with the system) I found that there are save cartridges and a saturn modem. Everything needed hardware wise. It looks like they made a internet(dialup) based version for saturn.
And final thoughts: It would be neat to see what sort of back end services they were using if those were in the recovered backup tapes. probably quite a bit more sensitive than releasing roms so may not happen.
As someone who is not a design snob (I tend to fall into the ontology snob bucket) the bit I liked is the way the types were categorized, there is the roman style and the egyptian style. And while roman was obvious "Ah yes like times new roman" egyptian was not familiar to me. Easy enough to figure out that it is what today we call sans-serif but I wonder when the term fell out of use?
Oh cool, I hadn't heard that term until you mentioned it. Apparently the name was in flux in the early days. The Wikipedia page for Sans Serif has an interesting footnote:
> master sign-painter James Callingham writes in his textbook "Sign Writing and Glass Embossing" (1871) that "What one calls San-serif, another describes as grotesque; what is generally known as Egyptian, is some times called Antique, though it is difficult to say why, seeing that the letters so designated do not date farther back than the close of the last century. Egyptian is perhaps as good a term as could be given to the letters bearing that name, the blocks being characteristic of the Egyptian style of architecture. These letters were first used by sign-writers at the close of the last century, and were not introduced in printing till about twenty years later. Sign-writers were content to call them "block letters," and they are sometimes so-called at the present day; but on their being taken in hand by the type founders, they were appropriately named Egyptian. The credit of having introduced the ordinary square or san-serif letters also belongs to the sign-writer, by whom they were employed half a century before the type founder gave them his attention, which was about the year 1810."
I was reading the superdome wikipedia page(as one does) and there is this amazing blurb on how in 1987 the jets once played to to an empty stadium due to a scheduling mix up. The idea was so compelling I spent a little time trying to find contemporary articles about the event (or non-event if you will). Unfortunately wikipedia's source is not readily available and I was not able to place the jets at the superdome in 1987. So just another unconfirmed weird factoid taking it's place among all the other unconfirmed weird factoids my brain likes to keep track of instead of actually remembering something useful.
In retrospect this falls into that gray zone There are vast quantities of information that are not on the web, There were probably articles written about this. but I am only willing to put the bare minimum effort into researching it, If I can't find it with a 10 minute web search it might as well not exist and the web search engines are getting dumber at an alarming rate.
Due to the nature of the sport (one person in a metal box, pit crews distanced from each other), after an adjustment period NASCAR races happened during the pandemic. To empty stands. The winner would get out of the car and instead of thunderous applause, or boos depending on the driver, there would be absolute silence. The word surreal is overused but it was that kind of experience for the driver and people watching at home.
On the topic of plain text databases, I have been playing around with wordnet(basically the backbone data structure of a thesaurus ) and while there are a lot of perfectly good libraries to handle the data I was having fun building my own. One interesting thing is that the original data format has the byte offset of every record and link baked into the data, this makes it trivial to avoid having to load the whole thing into memory and you can directly seek to the record in question thus making it a plain text database. Admittedly one only good for reading as writes would have to rebuild all the indexes.
Honestly now days the whole thing can be trivially loaded into memory but back when the project was started this was much more of a concern, I do know that once I figured this out I started re writing my program to see how little memory I could use, It was a lot of fun to use access patterns other than "load the whole thing into memory"
Have a look at cdb. The more you read about its simplistic design the more you realize it is damn near the perfect solution for static and semi-static datasets. Fetches are either 1 or 2 disk reads depending on if the key exists.
I don't really want an e-ink "monitor" as that does not really play into the advantages of an e-ink display. By the time the e-ink display is uprated enough to act as a monitor It feels like a lot of the advantages of e-ink are lost and the display server does not really downrate enough to utilize e-ink's strength.
But an e-ink "terminal" would be nice, not an actual tty but something more like a tablet form factor that has a few buttons, little to no internal smarts and you can push images to it.
Yeah... I bought the regular version a few months before the bigger one was announced. Now I kinda want it but can't really justify it at this point. It's a cool product though and a lot of the code is open source or has open source alternatives (e.g. the official backend is not but they have sponsored the development of open source alternatives so that if they go out of business or something you can host your own backend).
Needlessly pedantic because the distinction between multi process with explicit shared memory(shm) vs multi threaded with implicit shared memory probably does not really matter all that much.
reply