I have so much fun with my PiDP-11 that this will have to go on the list.
Does anyone know if MIDAS has been recreated for it or not?
A bit of the hint on the PPT reader, which would be awesome, the rp2xxx chips PIO can handle that with ease. As the PDP1 doesn't have take-up it is pretty trivial to make at 'historic' speeds. Obviously punching is much more difficult.
I looked into it for quite a bit, but not having access to tapes, puncher, supplies etc... I gave up on the idea as the PiDP-10 will scratch my personal nostalgia itch a bit more right now.
There are some versions of MIDAS around on bitsavers but I have to admit i haven't really looked into them much yet. Gotta leave something to the community, right? (or so i tell myself...). Another thing is that not all PDP-1s were the same and especially the PDP-1/X at MIT was a super hacked up version. Any code for that will not run my emulation (at least for now).
A real tape reader would be great and is something we are considering for the future, but without a punch it's not very satisfying. There will be a paper tape visualization though (currently writing the code for that).
There are multiple aspects and opportunities/limits to the problem.
The real history on this is that people are copying OpenAi.
OpenAI supported MQTTish over HTTP, through the typical WebSockets or SSE, targeting a simple chat interface. As WebSockets can be challenging, the unidirectional SSE is the lowest common denominator.
If we could use MQTT over TCP as an example, some of this post could be improved, by giving the client control over the topic subscription, one could isolate and protect individual functions and reduce the attack surface. But it would be at risk of becoming yet another enterprise service bus mess.
Other aspects simply cannot be mitigated with a natural language UI.
Remember that dudle to Rice's theorm, any non-trivial symantic property is undecidable, and will finite compute that extends to partial and total functions.
Static typing, structured programming, rust style borrow checkers etc.. can all just be viewed as ways to encode limited portions of symantic properties as syntactic properties.
Without major world changing discoveries in math and logic that will never change in the general case.
ML is still just computation in the end and it has the same limits of computation.
Whitelists, sandboxes, etc.. are going to be required.
The open domain frame problem is the halting problem, and thus expecting universal general access in a safe way is exactly equivalent to solving HALT.
Assuming that the worse than coinflip scratch space results from Anthropomorphic aren't a limit, LLM+CoT has a max representative power of P with a poly size scratch space.
With the equivalence:
NL=FO(LFP)=SO(Krom)
I would be looking at that SO ∀∃∀∃∀∃... to ∀∃ in prefix form for building a robust, if imperfect reduction.
But yes, several of the agenic hopes are long shots.
Even Russel and Norvig stuck to the rational actor model which is unrealistic for both humans and PAC Learning.
We have a good chance of finding restricted domains where it works, but generalized solutions is exactly where Rice, Gödel etc... come into play.
They were dealing with small datasets or infinite datasets, and double decent only really works when the patterns in your test set are similar enough to those in your training set.
While you do need to be mindful about some of the the older opinions, the fundamentals are the same.
For fine tuning or RL, the same problems with small datasets or infinite datasets, where concept classes for training data may be novel, that 1992 paper still applies and will bite you if you assume it is universally invalid.
Most of the foundational concepts are from the mid 20th century.
The availability of mass amounts of data and new discoveries have modified the assumptions and tooling way more than invalidating previous research. Skim that paper and you will see they simply dismissed the mass data and compute we have today as impractical at the time.
Find the book that works best for you, learn the concepts and build tacit experience.
Lots of efforts are trying to incorporate symbolic and other methods too.
IMHO Building breadth and depth is what will save time and help you find opportunities, knowledge of the fundamentals is critical for that.
In my experience, it was the need for orchestration that killed it but we are probably using different definitions of "immutable", where in Chef context I think of it as the infrastructure.
For me the killer feature of ansible for me was the ability to gate based on remote state, which really was incompatible with the foundational engineering choices that were almost ideal for its original target.
When you were upgrading rabbitmq, postgres, etc... the view from other cluster nodes was critical, not the local view.
Both chef and puppets tried to graft on what they called orchestration, but was really just batch jobs.
Immutable infrastructure was fairly easy IMHO with chef if your architectural quantum was a machine, but not for situations where that quantum was a cluster, especially with data that needed to persist like with Cassandra etc...
IMHO, with this type of issue is often more likely blowing through the multixact cache or the query planner reverting to SEQSCAN due to the number of locks or mxact id exaustion etc.. It is most likely not a WAL flush problem that commit_delay would help with.
From the above link:[1]
> I found that performing extremely frequent vacuum analyze (every 30 minutes) helps a small amount but this is not that helpful so problems are still very apparent.
> The queue table itself fits in RAM (with 2M hugepages) and during the wait, all the performance counters drop to almost 0 - no disk read or write (semi-expected due to the table fitting in memory) with 100% buffer hit rate in pg_top and row read around 100/s which is much smaller than expected.
Bullet points 2 and 3 from here [2] are what first came to mind, due to the 100% buffer hit rate.
Note that vacuuming every 30min provided "minor improvements" but the worst case of:
25000 tps * 60sec *30min * 250rows == 11,250,000,000 ID's (assuming worst case every client locking conflicting rows)
Even:
25000tps 60sec 30min
Is only two orders of magnitude away from blowing through the 32bit transaction ID's.
45,000,000
4,294,967,296
But XID exhaustion is not as hidden as the MXID exhaustion and will block all writes, while the harder to see MXID exhaustion will only block some writes.
IMHO, if I was writing this, and knowing that you are writing an orchestration platform, getting rid of the long term transactions with just a status column would be better, row level locks are writing to the row anyways, actually twice.
Long lived transactions are always problematic for scaling, and that status column would allow for more recovery options etc...
But to be honest, popping off the left of a red black tree like the linux scheduler does is probably so much better than fighting this IMHO.
This opinion is assuming I am reading this right from the linked to issue [1]
> SELECT FOR UPDATE SKIP LOCKED executes and the select processes wait for multiple minutes (10-20 minutes) before completing
There is a undocumented command pg_get_multixact_members() [3] that can help troubleshoot as many people are using hosted Postgres, the tools too look into the above problems can be limited.
It does appear that Amazon documents a bit about the above here [4].
No connection to this project, but I also have a couple sitting around for "some day" The biggest issue is that most of the adapter boards that are often available are not that great, so having a board built from EDPiy is an option.
3-5 years typical, when I was looking at the newer ones at an auction site to play with most were IR with some bluetooth etc..
The link you provided appear to probably be IR based, but it was one of the brands that was a dead end for official docs when I was looking at them.
The newest ones seem to be using Periodic Advertising with Responses (PAwR) that was introduced in Bluetooth 5.4, but I couldn't find those type for a price I was willing to pay.
Nordic Semiconductors has an Apache licensed SDK and RToS, I didn't find the device and time to play with it but bookmarked it.
The same applies to risk-adverse, high profit genres and/or producer heavy ones like pop country. Obviously zeitgeist and even conventions and music theory play a role.
The Blues Traveler trolling with the song Hook using the melody from Pachelbel's Canon with lyrics explicitly calling this out wasn't noticed by almost anyone.
Obviously Pop heavily samples too, E.G. Tom Tom Club Genius of Love being used by Mariah Carey's Fantasy, but it goes beyond sampling.
The Rolling Stones pulling from artists like Fred McDowell and Led Zeppelin settled copyright suits on Lemon Song, Whole Lotta Love, Bring it on Home and Dazed and Confused etc...
The invention of the Fairlight Sampler may have lead to groups like the Pet Shop Boys sampling dozens of other works, but as the Stones and Led Zeppelin show it wasn't unique.
Well I guess the Pet Shop Boys were inspired by Grandmaster Flash, and if you listen to the original recording of West End Girls you can hear James Brown samples...not sure if that counts as "hip-hop" in that case or not.
As a bad guitar player, I can understand why even Rock and Roll pretty much grew out of artists copying R&B/Gospel artists like Sister Rosetta Tharpe, but inspiration vs copying is a fuzzy line.
But basically the tooling changed, not the methods which have complex and intertwined causes, motivations, and effects.
DeepSeek R1 is far better at producing maintainable, modularized code as a coding assistant as an example.
The big deal is that the distilled versions like DeepSeek-R1-Distill-Qwen-32B are good enough that anyone with a few old 1080 Ti's sitting around can run them and get most of the performance.
When you can run gemma3/qwq/DeepSeek-R1-Distill-Qwen-.../etc... you can easily switch models when one fails too.
And you have consistent performance that doesn't degrade over time, have the ability to avoid leaking prompt data between client etc...
It is all horses for courses though. For me o1-pro is roughly the same as o1 with just higher limits etc... but is still worse than o1-preview IMHO.
In my experience the few percentage points on synthetic benchmarks that o1-pro was claimed to have doesn't matter much in real world problems.
R1 pretty much matched o1-1217 on every benchmark and the distilled models like DeepSeek-R1-Distill-Qwen-32B only lost a tiny fraction.
A few months of o1-pro costs will get you a local usable model of GPUs if you are fine with ~20 eval tokens/sec.
But if o1-preview wasn't better for your use case than o1-proe...the calculus can change.
Obviously 'fake Agile' is an industry wide problem here. But if teams cannot control their capacity expectations, it will always devolve to this
'slack' was a poor term to use IMHO, but it is here.
In companies that care about med/long term survival and success can fix this over time.
Selling it as derisking on strategic and initiative time scales is one way that can help.
reply