It's not just manifold geometry that makes the difference, though.

The biggest difference is in having a real parametric history. You can mimic a lot of this in blender by stacking modifiers, but at a certain point, you end up needing to apply the modifiers (eg. to make a single edge of a boolean "real" so that you can apply a fillet, for example)

If you later need to make a modification, any of the actions that happened before you applied the modifier stack are now lost. With certain edits you might be completely stuck because there's no way to adjust that particular element without either having to manually retopologize the entire model, or cutting large sections of the model away and rebuilding it.

But, in a parametric CAD, you just go to the step in the history and change your parameters. All subsequent steps recalculate. (When it works, that is. It's still possible to break things this way too. No system is perfect.)

This doesn't make blender bad. It's fantastic, it's just not designed primarily as a precision CAD modeler. Conversely, I wouldn't try doing character animation in a CAD app. Some tools are just optimized for certain workflows.

Unless you're the type of person that can't make it 35 seconds into a show without 'splosions or some ludicrously choreographed martial arts sequence ... I've never understood the "starts slow" characterization of Breaking Bad.

I get that label a little more for the Better Call Saul spinoff, but even there, the character writing was deep and good, so it made up for the less "wacky adventure" nature of the first couple seasons.

I've done design work using OnShape (browser-based CAD) on a Chromebook just fine.

I doubt it would hold up to complex assemblies, but creating basic parts for 3D printing was totally doable.

People are going to learn better if there is some applicability outside the classroom. Nobody is writing anything in Racket outside of their homework assignments.

But, if you pick a language (any language) that students can use to do actual things, they'll be more likely to do more than just learn enough to complete the assignment. I learned more from poking around in BASIC (as bad as it is) on Atari and Commodore computers than I learned in college programming classes, simply because I had to keep expanding knowledge to do new things, whereas the college assignments I only needed to do enough to be graded. (And I've never touched Modula-2 outside the classroom.)

I'm not a big python fan, but at least people can actually use it outside the class, as many applications use it as their built-in scripting language (eg. Blender, FreeCAD, etc) and there's even applicability to hardware (MicroPython, CircuitPython) which cna bridge to other CS-related tasks as people can mess with inexpensive microcontrollers.

Of course, you can do all this with C, as well, but a higher level language is typically an easier thing to understand for people that haven't ever programmed before.

Have you seen the show?

Because (spoiler alert) by the end, it pretty much ruined the life of everyone who was involved, or even knew someone who was.

To be fair, if it's anything like the ones I produce, it's not that the data doesn't require calculations, it's that the spreadsheet is just the final output format from another process that does the heavy lifting.

The real work is in the database, the XLS file just is an easy way to distribute the resulting data in a way that nontechnical users can filter, sort, and add fields to. But any of the calculations were done behind the scenes creating the file and aren't ever part of the output sheet.

They make excellent proof-of-concept development systems. They're easy to program, have a numerous GPIO pins making it easy to interface with other sensors or specialty hardware.

Outside of prototyping, I've seen them used as the base system for digital signage systems, to act as intermediary controllers that add networking capabilities to legacy CAM systems (3d printers, routers, plotters, etc.), and as a low cost way to build dev clusters to ensure software will behave correctly.

In addition to the full systems (Pi3, Pi5, etc), they also produce microcontrollers (Pi Pico) so that opens up some other opportunites in developing IoT devices (in the space typically occupied by Arduino, ESP32, etc.)

Not a human character, but Duracell and Energizer have fought over the pink bunny since the 80s (which started with Duracell in the 70s, and was picked up by Energizer to directly mock the original Duracell ad when Duracell let the trademark lapse).

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3F...

Now, depending on where you live in the world, you may see the character associated with one or the other company.

The funny thing about the Coleco Expansion Module (at least the Atari one, IDK about others) is that it pretty much was just a standalone 2600 clone (they were sued by Atari) - just a couple components shy. I don't know what the cost was, but if it wasn't significantly different, there's no real advantage over just having both systems (other than space, and that most TVs of the era only had a single input.)

The Coleco isn't supplying any computing power to the expansion module. It only supplies DC, and a clock signal. The expansion module returns a video signal that goes directly back to the Coleco's RF modulator. This has caused problems for retrogamers that have added video upgrades to their Coleco (like RGB mods) as the expansion module video is a completely separate signal, so even if you RGB mod your Coleco, anything running on the expansion module can't output over it as the video signal for that is already composite and fed directly to the RF modulator.

It wasn't just affordability. The 2600 had a two-year market lead on the Intellivision.

Of course this meant there were technical differences (in the INTV's favor) but it also meant Intellivision was competing with an installed base.

A kid with a 2600 could borrow cartridges from friends. The kid with the Intellivision might not even know another INTV owner. So, a 2600 user had a much bigger library of games at their disposal.

Yeah, the 2 year gap meant that the Intellivision was more powerful, but a couple more years and INTV was competing against Colecovision and Atari 5200, both of which completely outclassed the Intellivision (and 2600) but even those didn't end up dominating like the 2600 because of the legacy installed base. It wasn't until the mid 80s when the NES appeared (and Atari corp was massively fumbling) and was enough of an upgrade that publishers were able to stop worrying about the 2600 as people bought their "next generation" of gaming system.

If it's a bias that can be (somewhat) alleviated by randomization, then MORE small tests would help rather than fewer large ones.

With more tests, you'd scatter the error potential over a bunch of relatively small exams, effectively rendering it moot. With fewer tests, bias on any one has a much greater impact on your standing overall.

(And probably needing a pseudorandom distribution rather than true random to ensure some unlucky kid isn't the victim of long-odds and always landing at the back of the pack.)

ip.com has been doing defensive publishing for over 20 years in their "Prior Art Database" product. (Which includes old IBM TDB docs).

It's not free, but part of the cost is that they produce printed materials with hashes of submitted documents whose time of origin can be legally defended because you have the bibliographic information and the document hash in a printed volume at a particular date.

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fkb.ip.com%2Fpad%2Fknowledg...

It's not about devs updating their desktops. It's about being unable to connect to servers running 18.04 (which is still supported in ESM from Canonical) and not being warned that the update would break this connectivity.

Nobody is running 23.03 on their server. If you run Ubuntu on a server, you're sticking with the LTS releases. So, yes, there are newer LTS releases (20.04 and 22.04) to choose from, but that's missing the point of the LTS releases entirely. The whole reason you install the release with 5 years of standard (and 5 more of extended) support is so you can run it for a long time without having to deal with unexpected changes in the underlying system that could affect your applications.

I don't necessarily blame MS for dropping support. Just because Canonical pledges support for 10 years doesn't mean Microsoft has to. BUT, if you want devs using your product, you need to be aware of how they're using your product and try not to completely mess them up. Advance notice and/or a warning so that automatic updates wouldn't have broken workflow would have gone a long way.

Yes, Apple does pre-install their browser. And the App Store is the "preferred" method for software, and NOT where you'll find alternate browsers ... but never has my system bugged me about making Safari my default browser again after I've installed an alternate. Nor did it make me go through any type of "are you sure?" type prompts along the way.

Possible that it was a result of the faulty BASIC that came with the XL series. Revison A BASIC (from the 400/800) had a bug. In attempting to fix it for Rev B (XL series), they corrected it in one area but the fix introduced an issue in another. It could cause memory to get used up and lock the machine, and the 600XL already was memory constrained.

The fix was fairly simple: just order the Rev C BASIC cartridge from Atari (if you plugged a cart in, it would bypass the built in BASIC) OR there was also a short program you could type in and load from cart or disk that would poke the fix into memory. Sort of the bummer of having software on a chip, makes it harder to patch. (Rev C was standard by the time the XE series was released.)