If we did the same work but didn't have those things, we would need more people employed to make up for it. But if we didn't have those things these days, we probably would have less companies doing this sort of thing.
If we didnt have word processors or templated document generation, we would have people who write things properly, typeset documents etc. If we didnt have compilers etc, we would have people who translated higher level languages into machine code
That's what I also think. Without those inventions, we would more or less have the same number of white collars, only doing another type of job. I don't really know the economic and social consequences of this other reality, but from my naive point of view employment rate are a function of the economical activity, and not of the specific type of work done.
I'm not surprised that Justin Earl of Falcon Technix hasn't really advertised themselves on the page, I'm not sure I'd really want to put my full name on it either
Holy LLM, batman! The press kit, RSS feed, privacy policy and TOS links at the bottom of the page just redirect to the archive page, maybe get the LLM to remove them for you or actually generate a page?
Log all codas to a blockchain (with actual audio) would be cool. I like how this researcher only releases peer reviewed data and doesn't over-promise. Very cool. I think most of knew this was happening but could never prove it like he has.
Our saas had an internal-use, undocumented, publicly accessibly but not publicly used (by us) health endpoint that included an internal version number.
We removed the version and a few customers complained we broke their stuff.
I landed a massive database upgrade on a payroll system years ago, end-to-end standardization, cleanup, and improvement with a seamless rollout.
Our back clapping was interrupted by an angry customer phone call. One of our customers had gotten access to our internal schema and had a massive reporting setup in Access solving most of his needs.
I ended up converting his reports using some internal tools we had. Customers will grab anything to give them.
[The caliber and depth of his reports were such I wish we would have bought them instead of making me spend months building out our own reports.]
I had one customer that managed to figure out which stored procs were tied to which reports we were using. Then he would deliberately break it in weird subtle ways them and call tech support 'just to see how we would react'.
If the manufacturing for the 2.4 meter mirrors existed a decade earlier, and Hubble used the existing processes, does that mean all the KH-11 satellites also have the spherical aberration problem that Hubble has?
The spherical aberration of Hubble's main mirror was caused by a manufacturing defect.
Perkin-Elmer designed a new null corrector to verify that the mirror was made to spec, but the null corrector was incorrectly assembled (one of the lenses was out by a few mm). They also used the previous null corrector to test, which showed that the mirror was incorrectly ground, but decided that the new null corrector's measurements was correct.
But wouldn't they have needed to do that for KH satellites too? If they're making new equipment and processes, they'll be saving a lot less money from using KH mirrors
It was a new piece of test/validation equipment used on Hubble first. Reread it, they used the new equipment to test Hubble that had an error during assembly, they also crosschecked against the old machine which showed the mirror was flawed, and incorrectly decided that the newer machine was correct when it passed the Hubble mirror.
The test equipment is a much smaller part of the cost than developing, building and testing the machines required to actually grind the mirrors to spec in the first place.
or hubble has the aberration because the design optimized for cost on that bandwidth, because nobody would ever need to zoom individual fibers on a newspaper page? remember those where pointed the other way around.
but that's an awesome rabbit hole you pointed out!
Because at my work, clients want the general public to be able to install their apps sometimes, and my department does native apps, a different department does web stuff. If you want Joe Public to be able to install your app, you have to go through the Google or Apple stores.
However, we don't directly dev in Kotlin or Swift, we use Unity, which can export directly to an APK, or an XCode project (which has to be compiled a second time which is a nightmare). Sometimes we have to write native plugins to access device specific features (Last time I needed to was to access the FoV of the device's main camera), but it's not common, Unity has great support for most things you want to do out of the box
EDIT: I forgot, there are some situations where we supply an android or ios app to clients through our own app store, but I believe that devices have to be "enrolled", especially for ios. Generally though, Joe Public will want apps through the official stores
Does anyone know how these actually worked under the hood? Was it essentially just a mounting solution, and you wire them up how you need on the back, or were they essentially pluggable modules with some kind of control system attached to the board? I can't imagine it's the second option, given the timeframe, but I kinda want to see a system like that now
The German signalling is built around _Fahrstrassen_, literally 'roads to drive on'. Each one has a start and end point, and the station designer comes up with the ones to implement like 'from entry signal X to platform 1'. These 'roads' are usually a strict subset of the physically possible settings of all the switches.
In the old mechanical lever boxes, there were three kinds of levers: 'elements' (switches, derailers, gates), 'roads' and signals. To let a train move along a road, you first had to set all its elements correctly, and the road lever would only unlock when this was done. Pulling the road lever would also lock the associated elements in place. Then, you could 'open' the signal lever associated with the road, which is only unlocked when the road lever is pulled.
The interface in the page is built of modular components for elements and signals, which behind the scenes are connected to 'road' circuits. You select a road by holding the button at the start and pressing the one at the end. This tries to set up all elements along the road correctly, locks them electrically (with relays) if this succeeds, and then switches the signal at the start of the road. Obviously, the safety property is that you cannot set a road (or an individual element) while it is locked by another road, and no two roads can ever conflict with each other.
Commonly these components were modular just based on some of the ones I've handled decades ago.
Imagine a configurable rotary switch.
You have the knob part available in a selection of styles and colors.
You have the switch body, which can come in different types, single pole, two pole, NC, NO ext. One I saw you could stack them.
Then you had a basemount with terminal connections, screw, solder, etc.
I've handled decade encoders, stackable numbered encoders. The more convenient ones the the computer could read the selected numbers like you do keyboard matrix.
The actual logic (mechanical relays, timers, potentiometers and the like - analog modular setups built by electricians) would have sat in an electronics cabinet separately from the dashboard, which itself would have had simple lightbulbs, dials and buttons.
The former, although there is usually some system with change control documentation for the actual rat's nest behind the panel; the panel mounts themselves can be remarkably modular with swappable and stackable contact switches, etc.
They're mechanically modular. They don't automatically get data somehow. After assembling the control board to your liking, you still have to wire each individual component.
It should probably be noted somewhere that this is more "papercraft" than "origami", and the thing you download is just the net of the solid, not instructions to make what's in the picture.
Some of the platonics have folding instructions not just the papercraft net but yeah I wish some of the more interesting ones had actual instructions for the thing being shown too.
The instructions seem rather sparse, like the Archimedean solids only have folding nets, and not the folding instructions that produce the cool looking pictures with the holes in the faces.
Even for the intersecting tetrahedra where instructions are available, I see that it's basically constructing the edges from 30 pieces of paper and then assembling them together. I wish they have more things that were built from a single square piece of paper.
It's definitely disappointing and feels like a lazy site to not have much more than "look at these neat origami representations of these shapes.
Building from a single sheet is pretty limiting and beyond a cube build like the classic inflatable lantern you'd likely need glue to hold the folds down I think.
Maybe it is a work-in-progress and they just didn’t get around to doing all of them (it’s probably a lot of work). Most of the more complex/compound ones don’t have instructions or nets at all. The paper models are still very beautiful.
I looked at the page, and decided I wanted to see how to origami some of the archimedian solids, which are lower down the page. I don't find platonic solids as interesting so I didn't click on them. I saw they existed but you can't see that they have folding instructions unless you click on them
Less than a half dozen of the things on that page have a set of actual origami instructions available. I can completely see missing the few out of all the others because they're the less interesting items on the page.
If we didnt have word processors or templated document generation, we would have people who write things properly, typeset documents etc. If we didnt have compilers etc, we would have people who translated higher level languages into machine code
reply