Where?
https://www.congress.gov/bill/118th-congress/house-bill/7521/text

If I understand that website correctly, your linked page is just a draft that only passed the house. The actual passed law (a different version) was embedded in another "related" bill ( https://www.congress.gov/bill/118th-congress/house-bill/815 ), which includes the following sentence:

I don't know how well Trump's action actually meets those privisos...

From the Nov 1 story on slashdot: "US Experts Say Headlights Aren't Bright Enough" https://tech.slashdot.org/stor...

For what its worth, I agree with this newer story and completely DISAGREE with that earlier one.

In fact, in that one I actively complained about tail lights, let alone headlights: https://tech.slashdot.org/stor... . Everyone is trying to out-bright everyone else, with no sign of reaching a reasonable balance...

The specs seem like only a rather tiny incremental step towards the upcoming PlayStation 9 ( https://www.youtube.com/watch?... ).

They seem to be releasing new console versions too quickly: We've used more than half the version numbers already, but it has been less than 1/3 of the time elapsed until the year 2078. They'll need to substantially slow down the release of new versions if they expect the PS9 to have anything like the advertised features...

Personally, I think some cars' taillights and brake lights are too bright, let alone headlights.

Everyone is trying to out-bright everthing else, increasing brightness more and more on a continuous treadmill. Everyone has studies that if they just make their own lights brighter, drivers will notice them better and avoid hitting them, possibly stop and shop at their store, etc. That's true when considered in isolation, but it ignores how that now makes it harder for drivers to notice anything else besides your now-brighter taillights, storefront signs, etc.

I suspect it would be beneficial to try to achieve a better balance, making everything dimmer (but balanced by priority), with the ultimate goal of trying to preserve enough of a remnant of people's night vision that they might have a chance of noticing hazards that aren't directly illuminated at all...

#1 is wrong, DEI prioritizes hiring on the DEI principles WHEN the competence is equal.

In theory.

In theory, "from each according to his ability, to each according to his needs" seems like an excellent and fair way to distribute resources.

In theory, with respect to voting there seems like a lot of sense in the idea that someone should demonstrate some minimal level of competence in planning and running their own lives before they are allowed to have a say in running a country.

(There are probably many more.)

But in practice...

... (the US, which does the lion's share of global space spending, hasn't sent a dedicated mission to Venus since 1978).

Pedantically, there was the Magellan mission launched in 1989. But your overall point still stands... https://en.wikipedia.org/wiki/Magellan_(spacecraft)

Epic already lost its suit against Apple months ago.

I'm not an expert, but doesn't it seem like the legal results are backwards (assuming different results for the cases are legitimate at all)?

Unless I'm mistaken, it is officially allowed and fairly straightforward for a user to install anything on Android without going through Google, but IOS only allows that if you (as a user) sign up as a developer (including a fee, I think). Doesn't that mean Apple is a worse/stronger monopoly than Google?

Along the same lines, there is also Benji Smith's 2005 hammer factory factory post on the now-defunct joelonsoftware discussion forum. The original is long gone, but there are at least two copies elsewhere:

https://factoryfactoryfactory.net/

https://medium.com/@johnfliu/why-i-hate-frameworks-6af8cbadba42

(The original also had some good follow-up discussion, but that is harder to find.)

I agree OAuth2 is a real PITA; I've got a few gmail accounts and it has been getting insane. They don't really seem to want to support POP/IMAP and other non-"gmail.com" web clients. However, there are some options:

I'm not sure if it still be possible to leave 2FA off on an account that it decides is low importance (like if it only ever receives mail from public mailing list subscriptions). It seems to be more and more difficult. In the last few years they added logic that (sometimes) disables access if they detect you trying to access it from unexpected IP address ranges you aren't "normally" using (such as when (rarely) travelling). This basically forced me to enable 2FA on all of my gmail accounts.

Last I checked, it was still possible to enable and generate "application passwords" that you can use in any POP or IMAP client, but not for any other kind of access. (Unless you are using business class "G Suite" and your company's admins disabled the application password option.) Most of my accounts are still using application passwords, and I occasionally get emails about "improving" (scare quotes) my security by disabling them, but maybe I'm just grandfathered in? (I could log in with my browser and check what settings options are currently in gmail's settings, but I disable both javascript and cookies from most places by default (especially Google), and I don't feel like going through the hassle of temporarily opening holes in my personal security policy right now (and tracking down passwords and TOTP secrets for "second factors") just to refine this comment.)

Finally, if nothing else works, I try to maintain some instructions on how to use oauth2 to maintain a normal local UNIX email account routed through gmail, as a kind of public service. See https://mmogilvi.users.sourceforge.net/software/oauthbearer.html. This requires carefully setting up a lot of little details, but once it is working it seems to be possible for cron jobs to keep using a renewal token for years without manual intervention. The instructions, scripts, patches, etc could probably all use some updates, cleanup, and streamlining, but I think all the currently-critical tidbits are there. Including a workaround for google's recent decision to disable so called "out-of-band" initial token acquisition a couple of months ago. I use this for a single account, just to make sure I notice and can try to document it the next time google decides to break something.

I'm too young for the 1960's original, but there was a Scientific American article about how to write a clone of Spacewar back in the late 80's, probably in one of the regular "Computer Recreations" articles. Most of the articles were interesting - this wasn't the only thing I learned from them. It might have been February 1987, but I'm not sure (the table of contents doesn't go into enough detail, I can't find a good index of the computer recreations articles online, and the printed version of this issue is missing from its place on my shelves - maybe because it is one I made relatively extensive use of?)

I did get a few versions of the game working on my hot new 80386, and it was kind of fun to play it against siblings. The development difficulties were more about the development tools and hardware I had, not with the game itself.

One option was GW-BASIC that came with MS-DOS 2.1. It had no knowledge whatsoever of the Hercules Graphics Card clone I had. Hercules was basically like a MDA (text-mode-only) adapter, but had some extra RAM and bypass circuitry around the core 6845 CRT controller chip to enable a "graphics mode" that basically dynamically reads font data out of character-position-based offsets into RAM rather than the intended font ROM, giving the appearance of a 1-bit-per-pixel graphics mode... However, basic didn't now anything about this card, and everything had to be done with individual peek's and poke's for individual pixels (no efficient line or polygon drawing utilities), which is extremely slow in an interpreted language...

Another difficulty was that the documentation I had (from a PC hardware books and a CRT controller book) for programming the HGC was incomplete. It mentioned the graphics enable bit in I/O port 0x3b8, but not the "enable the enable" bit in port 0x3bf, nor the altered 6845 settings when in graphics mode. As a result, I had to resort to a hack to get it into graphics mode to run my own programs, where I would run a demo/advertisement program for a CAD program that came with the computer, Control-C out of it while it was in graphics mode, and then blindly type the commands to run my own program. MS-DOS and BIOS didn't know about this graphics card to present prompts as text when in graphics mode. (Eventually, a couple of decades later, I finally stumbled over a website that described the missing details, although such details still seem to be hard to find today. Although I just now found this scan of what might be the original documentation: GB101_Owners-Manual_text.pdf.)

Another option was a UNIX system (Microport UNIX System V/386 rel 3, v 2.1). It has a C compiler that could generate reasonably fast and efficient code, but had no interactive graphics support at all (regardless of your hardware), and its memory protections/etc would make it far more difficult to hack graphics in than with MS-DOS (I never tried). However, partly motivated by a desire to write graphics programs, I used UNIX to develop a C compiler that would target MS-DOS. This compiler eventually worked reasonably well; I even worked on some of my college programming homework with it. If you are curious, I've posted doscc online under: Miscellaneous Software.

I had very limited assembler support for MS-DOS, using MS-DOS's "debug" program, which included a very limited assembler where you always had to supply addresses numerically (not symbolically) and it only supported 16-bit assembly. At one point I developed a hackish GS-BASIC wrapper that would give limited symbolic addressing support using multiple passes (insert placeholder bytes for instructions referencing symbolic addresses initially, then fill in correct addresses in a later pass based on addresses extracted from the first pass), but it was still awkward and very slow to assemble, and it still required really awkward hacks for 32 bit code (write the 16-bit equivalent with comments, add additional missing bytes between instructions (you needed to understand the machine language fairly well), etc). Later (roughly as the compiler was nearing completion), I wrote my own assembler and dissassembler in C, which were monumentally faster and easier to use... Even with a good assembler, assembly is still too low-level to develop anything substantial. The most notable thing I used these for was to develop my own "DOS extender" to support running 32-bit code (from my compiler) under 16-bit DOS.

Many decades ago most equipment (computer or otherwise) came with full documentation, circuit diagrams, development tools (for computers), etc. That was starting to die out by the 80's, and I still lament its demise. At least Linux, open source, and various documentation available online mitigates this somewhat.