I haven't seen enough history to know if that's normal or not, but I can tell you that the center of each of those blue "clouds" is a nexrad radar station. It's view is a wide cone from the ground upwards (technically a set of cones from each of the radar's tilt angles).
It's quite possible there is some lower altitude fog/precipitation/something that is only visible to the radar at it's lower tilt angles. But that's just speculation.
One of my weird hobbies is radar chasing storms, and all of that stuff is completely normal. NEXRAD is very sensitive, especially when it's in clear air mode (it has different modes depending on if it's raining in the area) and can pick up things like dust, birds, bats, and insects. There's also ground clutter from things like buildings, wind farms, and even cars.
These are base reflectivity images. Composite reflectivity products reduce the noise from around the radar stations. The old NWS Java site used to let you select between them. Raw base images seem to be unavailable on the modern moving maps.
It's interesting how more "amateur approachable" both old cars and old computers are. Old cars can be worked on by anyone with some basic tools and know-how, and old computers could be understood and programmed the same way. MacPaint was made by one employee.
I think this is partially why people want these types of objects. You can actually own them. You can understand them. You can mod them.
Modern cars, games, computers, etc. aren't owned anymore. They always have updates, and could be bricked at any moment if the manufacturer wishes, gets bought or goes out of business.
There's nothing preventing this from being the golden age of computers. The capabilities of the hardware are near magical. We just need to bring back the concept of ownership.
What really disheartens me with modern cars is that electric cars are much simpler than than cars powered by combustion engines, which could be a huge boon to the fix-it-yourself crowd, but car manufacturers now lock customers out of their cars, so electric cars don't have the opportunity to become hobbyist friendly.
There are small electric-car companies that let customers do what they want, like Edison Motors, but they make industrial-sized work vehicles. It would be nice if a similar small company started selling consumer cars, but the automotive industry is heavily plagued by bikeshedding (https://en.wikipedia.org/wiki/Law_of_triviality) to the point that large trucks and busses are allowed to do their thing, while subcompact vehicles have been effectively regulated out of existence.
Contrary to popular belief, EVs really aren't that much easier to repair, that's just a logical expectation from people without service experience based on the idea of less moving parts, but that omits that fact that electronics die too and EVs have more of them and under more strenuous loads.
Most of the faults on EVs come from dead electronics like a fried MOSFET or PCB trace, and coolant leaks inside the motor due to gasket failures derived from race-to-the-bottom cost cutting designs to save money, which your average user won't be able to repair themselves unless maybe we're talking about completely swapping out the entire ECU/motor/battery/assembly with a brand new one instead of repairing it, parts which haven't been designed for easy repairability. And that's excluding DRM issues and the fact that those parts aren't sold to consumers and even if they would, stuff like ADAS sensors, motors and batteries still require calibration with dedicated equipment during installation and can't be plug&play like a laptop battery swap.
Check out EV clinic(no affiliation) for horror stories on EVs and hybrids failures. Due to poor design, a lot of EVs (maybe excluding Teslas) are reliability ticking timebombs whose failure is a matter of WHEN not IF.
That's what I was complaining about; non-commercial production EVs could be much easier to repair than any other vehicle type, but they aren't. Car manufacturers, for both combustion and electric vehicles, can and do lock out components to prevent end users from servicing and repairing their own vehicles. If modern batteries and IGBTs existed decades ago, we would have had a period of mass-produced electric vehicles that were as easy to work on as a Model T. Really, electric vehicles have existed since the Model T, but none of them ever sold well, because they were to slow and had too little range.
People DIY their own EVs all the time, and on the electronics side all you need is a battery, a battery management unit, a charge controller, a motor controller, and the motor. Some of those parts can even be integrated into a single module If your combustion-powered car is fuel injected, it probably needs just as complicated of computer systems as an EV. (with the exception being rare cases of mechanical fuel injection)
The rest of an EV drivetrain is the same as any combustion car, except the transmission can be much simpler or may not be needed at all.
If an electronic components dies within one of those modules, swapping it out is no more work than swapping out something like an alternator or a starter. If the motor itself needs replacement, that's much, much easier than swapping out a combustion engine. Most electric cars have motors small enough that a single person could lift and carry one. If your motor controller died, you might be able to fix it with board level repair, just as you could rebuild an alternator yourself, but almost everyone working on a vehicle, whether DIY or commercially, is going to replace it, with either something new or something repaired/rebuilt by a specialist.
It's possible to get EVs with cheap components that won't last long, but it's also possible to get components with good design and build quality that will last a lifetime. Combustion engines, on the other hand, are regulated into designs that have extremely high efficiency when brand new, with no care for their long-term performance, so pretty much any modern consumer combustion vehicle has extremely fragile piston rings that begin leaking almost immediately, making for much shorter lifespans than decades-old combustion vehicles.
Driver assist is completely unrelated to the fuel type and open-source solutions do exist, that work on both combustion and electric drivetrains.
In theory they can be mechanically, in practice high ADAS standards and functionality like regenerative breaking make it feel like a pretty high risk proposal to allow an end user in.
It doesn't take much to make a battery pack safe to work with. Every EV I've seen has contactors on both battery terminals, as well as physical shunt that is removed before servicing, in case a contactor fails closed. There's usually also contactors within the battery, making it possible to work on the battery pack itself, without any unsafe voltage present.
It's no more difficult to make safe than household wiring, and DIYers work on it all the time.
Electrically, regenerative breaking just runs the motor driver in reverse (or really, out of phase) and it doesn't take any extra components, only requiring a few instructions in the motor drivers firmware. It's not anything a DIYer has to even know exists, let alone mess with.
Driver assist has nothing to do with what type of fuel and powerplant a vehicle has, and those features can be broken by DIYers on any vehicle type. Sometimes being able to disable them is a built-in necessity for safety, for example when driving on gravel roads where they tend to do more harm than good.
Its not about the actual mechanism of regen, it's how it interacts with the other systems on the car.
Modern ADAS is a whole lot more integrated on EVs than it ever was on combustion cars, not by some inherit requirements of EVs but due to consumer demand when considering a new ev platform.
The driver is increasingly more removed, things like drive and break by wire go through a long chain of controllers in order to allow ADAS, and the input from the user is really just one more signal from a sensor.
There is no longer any circumstance where these systems are completely "off". And none were I would consider off to be safer. (Yes, even gravel and snow)
> It's interesting how more "amateur approachable" both old cars and old computers are.
Right.[1]
I think of those guys at the Computer Museum who took years to repair an IBM 1401. They even had the assistance of some of the designers and retired IBM field engineers.
Comparing this mac that can be found on ebay at any given time with a 1401 feels a bit like comparing it with getting one of the first steam trains. I am surprised they made 12000 (according to wikipedia).
Old cars are wonderful except for one thing: safety. Modern cars are just so much safer with crumple zones and airbags. I would never want to use an old car as a daily driver.
The Z80 is a legend, and even though it's not powerful by today's standards one of the things I think makes it great is it was a "standard". There's something very powerful about a platform that doesn't change.
I'm really hoping raspberry pis can fill the roll of a "standard computer". Currently, they have pretty rapidly changing CPUs, etc. I would like to see a pi that settles down as "The Pi" that doesn't change for decades. This would allow all kinds of software (and OSs) to be written for it that stands the test of time. Download a binary and it just works. No need for updates/changes etc.
I recently started using Janet and enjoy it too. I think Rich Hickey got it right when he created a single set of functions to operate on all collections, which fixes most of what's mentioned in the article. Janet does a great job of copying what Clojure got correct.
I've found the documentation for Janet to be fairly adequate. What are some parts where the documentation could be better?
Michaelmas Term was the only phrase I didn't know. Apparently it's still used in the UK (and I'm not from there).
Proper nouns are trivia though. The more important part of the document is that students couldn't tell the difference between what was literal and what was metaphor. For students that were in their 3rd year of university as English majors, that's quite a problem. By that point they should have read hundreds of passages from books written in the 19th and 20th centuries.
This is so cool!
It's funny because open source devs are making Windows better while MS is actively making it worse. If MS removed all telemetry and AI (and restored win10 functions in context menus), I would probably move back to it.
I've recently started playing around with Janet, and it's a great language. I think it's inspired by Clojure and Lua, and somehow manages to be better than both (in my opinion).
> I think it's inspired by Clojure and Lua, and somehow manages to be better than both
This is exactly how I feel about Janet too. I don't think I have enough experience on Clojure or Lua to comment on them, but I got attracted to Janet almost immediately.
Working on Jwno also confirms my first impression on Janet: It's really a practical language. The tooling has some room for improvement, but the language itself can get things done - usually fast and easily.
How’s the REPL/interactive editing story? I feel weird using a Lisp that is not as interactive as Racket, Scheme or Common Lisp. Running scripts from the REPL ain’t the same thing as C-x C-e an expression on a live program
> I feel weird using a Lisp that is not as interactive as Racket, Scheme or Common Lisp
I think Racket and Scheme don't belong in there because neither has a REPL as powerful and "interactive" as Common Lisp REPL. They don't support images either (but Janet and CL do).
As a Common Lisper with a Scheme background I'm gonna guess that by the interactivity of the REPL you mean the condition system with restarts? While most Schemes don't really have anything like it, I seem to recall MIT/GNU Scheme having something kinda similar. And I mean, hey, it's got Edwin, so it definitely has interactivity.
Yeah, it's mind-blowing when it clicks, and makes the whole "exceptions vs. return types" discussion look like a quarrel of 3yos in a sand box. Error handling in other languages/runtimes just doesn't feel sufficient from now on.
This is, of course, just a part of a larger whole - the fact that your Common Lisp program ships with a compiler it can access and effectively always runs in an edit-and-go debugger. Embracing this fact fully leads to a different workflow of software development.
Having done a bit of that, I found plenty of drawbacks of this approach, too - mostly various consequences of breaking the assumption that code that a program is running is the same as the code it was compiled from or that it started with. The aspect that annoyed me the most day-to-day was, basically, that whenever I fixed something on the fly through conditions and restarts and eval-ing code in a REPL, I never had a nice way to go back to that solution and port it to code. It was too easy to forget about a quick fix you did without thinking.
I now realized this should be easily fixable with external tooling - i.e. in Emacs/SLIME. What I think they need is a better way of keeping an audit trail. Capturing and persisting as much of the transient interactions you did as possible, letting you revisit them after and easily transfer into code or tests.
> I now realized this should be easily fixable with external tooling - i.e. in Emacs/SLIME. What I think they need is a better way of keeping an audit trail. Capturing and persisting as much of the transient interactions you did as possible, letting you revisit them after and easily transfer into code or tests.
To some extent, undotree on neovim allows this because it offers a drastically different view on what "undo" means. But I agree with you, the lack of a git-like system is annoying. I even think this might be THE reason CL didn't catch on—companies want to keep track of things (hence all the dashboards and ticketing systems...).
That's the other thing. Version control is tricky with image-based systems. I won't say impossible, I never looked deeply into what Smalltalk/Pharo folks are doing, but since between playing with Pharo and Glamorous Toolkit I saw Git being integrated first-class into one of them, I imagine someone has some idea how to deal with the problem.
What I meant though isn't collaborative/historical tracking, I meant day-to-day ergonomics; closer to "drastically different view on what 'undo' means", except it doesn't even have to be 'undo' - I don't need the ability to rollback every single thing; I just want to know whatever the hell I actually did an hour ago when I quickly SET-VALUE and IGNOREd my way through a few random condition popups and evaluated some code in between. Being careful and keeping track of this as I go slows me down and is kind of the opposite of REPL-driven interactive development ideas; nah, I should be able to go fast now, and later be able to review all the random surgery I did on a live image.
EDIT:
> undotree on neovim allows this because it offers a drastically different view on what "undo" means
As I understand it, this "different view" is treating undo history as a tree? If so, I know this from Emacs via similarly named `undo-tree' package. But honestly, the moment I saw this I thought this is brain-dead stupid most obvious way of treating undos. It's very unfortunate that almost no software embraces this approach, instead opting for a linear history that gets trimmed the moment you undo a few steps and make a change.
If you want to see a truly different view of undo, check out what Emacs does by default. I don't even understand it fully, but best I can tell after studying the explainer in undo-tree's documentation, is that Emacs is using a linear history like everyone else, but instead of moving back through the history and discarding "the future" when you branch out, `undo' itself is an undoable operation that gets appended to undo history, so when you type some things, undo it, type something else, and keep pressing undo, you'll erase the last text, then "undo the undo" and end up with the first thing you typed...
> Version control is tricky with image-based systems
Back in the day:
"ENVY/Manager augments this model by providing configuration management and version control facilities. All code is stored in a central database rather than in files associated with a particular image. Developers are continuously connected to this database; therefore changes are immediately visible to all developers."
"Package files are simple text files, encoded for latin alphabet (ISO 8859-15) and handled without problems by GitHub. Cuis-Smalltalk uses the LF (ascii code 10) newline convention, as preferred in GitHub. This allows Git/GitHub to diff versions, and merge branches."
> Yeah, it's mind-blowing when it clicks, and makes the whole "exceptions vs. return types" discussion look like a quarrel of 3yos in a sand box. Error handling in other languages/runtimes just doesn't feel sufficient from now on.
I am still waiting for a non-Lisp language with a half-decent restart system. Even compiled languages should be able to implement it (except dealing with a possible allocation failure when saving the register context to return to)
Restarts in CLHS are blocks of code handling a condition (exception). CL splits the "catch exception" and "react to it" parts into handlers and restarts. The two are independent; a handler can choose any restart currently installed above it in the call stack, or ask the user to choose interactively; the stack is only unwinded up to the point of a restart to resume from. This means you could e.g. following call stack:
5. Code that signals a file read error
4. Code that installs restarts "re-read line" and "skip line"
3. Code that loops over files in line
2. Code that installs restart "re-read file" or "abort"
1. Code with the handler that intelligently chooses whether to resume from 4 by re-reading a line or skipping it, or resume from 2 by attempting to read the file again, or just bailing out.
If we're still calling Guile a Scheme (I'm out of the loop) then I don't know, it gets really bloody close. Not so much in image-based development (that I've usually found less good than a decent packaging system because the contents of my files on disk is usually more tractable than the contents of my image), but its object system and error handling are definitely up there close to CL.
I mean, Common Lisp is still the gold-standard for me, but reading about Hoot recently really made me want to check Guile out a bit more (CL does not have much in the way of lovely WASM stories right now) and, honestly, I was super impressed. I think if the interactive experience of developing in Hoot in the browser matched the interactive experience of developing in native Guile, I'd be a pretty happy convert.
That's one of the best intro pages I've seen for a language. I really like how it has tabs for different practical examples (http, generics, coroutine, etc.).
I've started experimenting with Odin for some personal projects and it's been great. The built-in vendored libraries make creating certain programs trivial. For example, just `import rl "vendor:raylib"` and you can use `rl.InitWindow(800,600,"Test")`. No need to install Raylib, add to path or use special linker directives, just `odin build .`!
Also I think Odin struck the right balance of features while trying to keep to the spirit of C.
Well, we’re focused on extracting as much money as possible from people who try to pay loans with awful terms. Meanwhile, the banks have no incentive to do meaningful vetting as the loans are guaranteed.
It's quite possible there is some lower altitude fog/precipitation/something that is only visible to the radar at it's lower tilt angles. But that's just speculation.
reply