"The second approach was to use a digital computer to determine the solution. This solution was rejected because in 1963, a digital computer was expensive, slow, and less reliable."
This inflection point between analog and digital computer is a fascinating one. At one point in time a analog computer made sense and some later point in time you would be foolish to specify anything other than a digital computer. But that time between when it could go either way is interesting. There is a good autobiography by the person responsible for introducing the first digital computer to the navy that provides an interesting view into this era. https://ethw.org/First-Hand:No_Damned_Computer_is_Going_to_T...
Now I am vaguely searching for a guide on gear train schematic diagrams, I am sure they had them, you don't reason out something this complicated without one. I know hydraulics has it's own flavor of schematic diagram, which are fascinating if all you have seen are electronic circuits. https://www.hidraoil.com/technical-resources/hydraulic-symbo...
> No Damned Computer is Going to Tell Me What to DO
That is the best title for a story about replacing analog and mechanical instruments with digital computers. A similar process is happening now with natural intelligence, replacing or augmenting the human intellect.
While true your argument is weak, for example in pov-ray the shapes are pure exact mathematical concepts. But nobody is saying how great this is for 3d printing or general cad work because it's not. The real key benefit from these programs is the interchange format they can generate, something you can feed to a machine, this prevents it from ending up like pov-ray, a terminal process only fit for generating pictures. Fillets are difficult to do in openscsd because fillets are difficult to do in general. What your argument probably should have been is that if openscad had chosen a geometry kernel where fillets were already solved it could then do fillets. Which is the sort of obvious tautology that helps no one.
Now I am off to see if anyone has ever built an export plugin for pov-sdl, either a 3d rasterizer(g-code slicer) for 3d printing, or a boundary layer mesh generator for import into another program. language wise it is probably equivalent to or better than the openscad sdl,
One subtle advantage to using python as the sdl is that it gets access to the vast corpus of python modules out there. Most of which are probably useless. but one thing I want to try is to see if I can use sympy to define a more declarative style of constraint.
The REST term triggers me. It should not. I should just let it go. But whenever someone says REST 99% of the time they mean HTTP and 98% of the time it is json over HTTP. REST is a specific access pattern where you ship the application required to respond to the query with every query. It is the REpresentational State of the REpresentational State Transfer. And while REST does not have to be html the web browser is realistically the only piece of tech in our stack that can actually do something with a representational state, which is a long winded way to say if you are not shipping html your transfer probably is not REST. json is not REST. in fact REST is almost always a human interface thing. if your transferred data is intended to be processed by machine. it is probably not REST.
Really, i just find it funny how Roy Fielding said "hey this web thing is actually doing something really novel in data access patterns lets give it a name so we can talk about it" and everyone collectively had a huge brain fart and said "Got it. HTTP == REST"
With regards to printer rip(raster image processer) machines. We think of this as an easy task today but historically they had to be surprisingly powerful. When I bought my sgi o2 I found it had lived it's previous life as a rip. Which blew my mind, you have this 20000 dollar machine. and they were using it for a glorified print server.
Other examples are the first apple laser printer which was their most powerful computer by a large amount when it came out. And the anecdote of the sys-admin who traced mysterious long printer jobs that never printed anything back to an enterprising engineer who had figured out that it was the most powerful computer in the building and had rewritten some of his simulation code in postscript to take advantage of it.
No, no, you rejoice, a deterministic bug is the best sort of bug. because now you have a test case and a solid method to know when it is fixed. The sad bugs are the ones you can't find a test case for.
I also got a bittersweet chuckle out of how the author considers it a lightweight environment, I mean, they are not wrong, but think of how far we have fallen when e, the ultimate bling desktop environment is considered lightweight.
Back in the early 2000's, I used Enlightenment. I wouldn't have called it "lightweight", but it definitely was not heavy. It ran smoothly on my not-so-great-hardware. And definitely lighter than DEs like KDE/Gnome.
I stopped using it for other WMs. I remember how it was taking forever to release E17 and totally forgot about it. E16 was definitely awesome in those days.
> because now you have a test case and a solid method to know when it is fixed.
And where is fun in that? Where are now the nights in trying to reproduce it? Where are the doubts in the moments of rest "have i really fixed it, or is it still there"? Boring.
As someone who remembers E making the rounds among the BSD and Linux users in my college dorm when it first came out, there's no way he's only 21 if he was a baby in the late '90s.
"Hello! I’m Kamila Szewczyk (iczelia). I am 21 years old. I’m an expert programmer and aspiring mathematician, primarily interested in compiler construction, data compression, esoteric languages, statistics and numerical algorithms. ... Currently I am a full-time student based in Germany." [1]
And the start of the post:
"The editor in chief of this blog was born in 2004. She uses the 1997 window manager, Enlightenment E16, daily."
I guess they wanted to keep working on their slides (at least for the moment) and not be forced to go debugging. Sadly, the hang was deterministic, so they didn't have another option.
But it is light weight. Fabulously so. The "bling" just comes from the ability to write theme files to customize the appearance of window decorations and menus. IIRC it was a fork of fvwm from way back in the day, and similarities can still be seen in the config files. I use it on everything including old 32-bit systems, and it's snappy and responsive everywhere.
GP means that 25 years ago, it was definitely not lightweight compared to many of the alternatives (GNOME and KDE being notable exceptions; I wouldn't have called them "light" back then either). Toady it's certainly light.
Enlightenment up to e16 always was light weight. There was eye candy that could be enabled like transparent/wobbly windows and whatnot, which could drag down a weak system, along with the ability to add high resolution wallpaper that took up a lot of memory, etc, but the core of the window manager doesn't have any kind of bloat or slowness. It was always configurable to be snappy and low resource. Just like fvwm.
Even netflix suffers from this, for a while they were great, pay them watch anything. but then the traditional publishing houses started cutting their works off from netflix in favor of running their own streaming. which had two results, a balkanization of streaming video (you can't just go to one place anymore) and netflix investing into making their own content so they have something to stream.
"AMD’s AI director reports that Claude Code has become “dumber and lazier” since February, based on analysis of 6,852 sessions and 234,760 tool calls, which is the most thorough performance review any AI has received and rather more than most human employees get."
Are there any good ways to measure agent ability? Or do we just have to go by vibes?
Master/slave is almost always misused anyway. Yes one database will do all the work(we will call that one master) and the other will sit around all day waiting to take over(we call that one the slave). me nodding. yep that is about how it worked. postgres is a little closer where the master process hangs around not doing much, only really there to receive new connections which it then gives to workers to process. And don't even get me started on how IDE drives misused the term, I don't mind the master/slave terminology but if used it should at least capture some of the dynamic of that relationship.
I never did understand what they felt was wrong about git master, there was no slave or even work involved. it was more like the master print of a video. you know the thing that "remasters" are made from.
One is exactly as complicated to reason about as the other.
Except on one you don't need the trick.
reply