PumpkinSpice

> I know so many poorly educated homeschoolers whose lives have been destroyed with no hope of recovery by the complete lack of skills their hyper religious parents imparted them with, in jail, broke, unable to hack it in college and too lacking in common sense to make it in the trades or professional work, with living standards insanely far below their parents.

In pretty much all studies, homeschooled children on average fare the same or better than kids who go to normal schools.

While it's certainly the case that people with fringe views are more eager to homeschool their children, anti-homeschooling sentiments are really not backed by anything of substance.

I'm not here to defend SolarWinds, and it's entirely possible that they were a "bad investment pretending to be a good one", but I have some issues with this framing.

First, contrary to your assertion, there is no doubt that they're in trouble because of getting hacked by a nation state (and dutifully disclosed it). This wasn't some routine audit, wasn't a whistleblower complaint. The only reason the SEC went after them is that they had the misfortune of falling prey to an attack that few other businesses could conceivably repel. So, I'm not sure that's sending a great message.

Second, the complaint isn't showing that the company brazenly and deliberately deceived investors. It's not that the SEC peeked under the hood, immediately realized this is messed up, and had to act. No, they spend months poring over every email - and all they came up with is not exactly a smoking gun. The whole complaint is basically "the company only made generic investor disclosures, but we found instances where specific employees pointed out more specific deficiencies."

Ignoring the one-sided narrative of the complaint, the actual quotes they have don't paint the picture of a deliberate conspiracy. They paint the picture of normal day-to-day communications where people sometimes say dumb things, blow things out of proportion to try to get resources, etc.

"Directors and officers" are a special legal category, basically the highest-ranking people making material decisions about the business day-to-day. They are subject to special reporting requirements, such as having to file paperwork whenever selling or buying stock (which usually needs to happen under a trading plan). They often have specialized contracts, company-provided liability insurance, and a variety of perks you associate with "real" executives at public companies - from corporate jets to eight-figure salaries. We're talking about the CEO, CFO, CTO, and so on.

This is similarly-sounding but completely separate from the "director" job level at a typical tech company, which is basically just a senior manager of a large team or maybe the lead of a mid-size department. Your average CISO is probably in this ballpark, commonly at least 2-3 reporting levels below real C-leadership.

The password example feels egregious, but keep in mind that the investigators spent months if not years combing through corporate records and are now showcasing the most embarrassing finds in the framing of their choice. I bet there's not a single company in the world where some engineer didn't at one point set up a dumb password as a part of some one-off integration. The job of the security team is to systematically track down stuff like that, but you never reach 100%. There are things you don't see.

What feels particularly weird here is that SolarWinds wasn't compromised by a Bulgarian cybercrime gang. They were compromised by a nation state. While the SEC is notionally focusing on other stuff, this is ultimately the company's original sin. How many businesses, no matter how strong their security posture, can really say that they're immune to that?

No, the bulk of security and privacy work at Apple happens elsewhere.

In most public companies, CISOs are not "real" C-level positions. They're not considered "directors and officers" of the company in the sense of the securities law, they don't have special contracts, they don't rake in exorbitant salaries, they don't have golden parachutes. They don't routinely participate in board meetings or shareholder reporting.

If I recall correctly, at Apple, the CISO role was some guy reporting to the corp IT org, entirely separate from core products and services. And we're talking about one of the most valuable and sophisticated tech companies in the world.

Amazon had an even wackier model, with separate "CISOs" for different orgs, the term meaning not much more than "a senior manager that we can put in touch with clients if needs be." Google now has a "cloud CISO" who is a nice techie guy and talks to customers, but is not actually the person in charge of the overall Google security org.

I get it that the SEC wants to change this culture and have a designated person meaningfully responsible for infosec risk, but it feels that it's a case of stick before the carrot. They have the power to reinterpret their own rules to elevate CISOs before they start cracking down on them with personal liability lawsuits.

And I'm betting that just like in the case of Uber, the CISO will end up in trouble, while all the execs will get to claim ignorance and walk free.

Most of pop culture is derivative, and the benchmarks we use reveal more about our age than about true originality.

That said, the references to Control in this game definitely feel a bit hamfisted. You even encounter a familiar character from Control, and they seem to have a lot less depth than in the original game.

I don't think it's realistic as a fuel for cars, but "worldwide transportation" means more than that. I suspect they're talking about container ships, tankers, and such.

Ammonia is easier to liquify than hydrogen, and is in many respects easier to handle. However, it's definitely not something you want to have a spill of at a gas station or in your garage, and for that reason, it probably won't have "consumer" uses.

As far as industrial gasses go, it's certainly nowhere near the worst, and there's plenty of ammonia tankers on the roads today, but large spills do kill people every now and then.

Diesel engines operate at higher pressures and must be considerably heavier to achieve the same performance & efficiency. Not a huge issue for ships, trains, or cars. Huge issue for flying stuff.

What you're basically saying is "the model as trained can't do well at this task, so let's use our own cognitive skills to help it."

That's a problem for comparative benchmarking, right? You're no longer testing the model; you're testing the model in tandem with the prompt engineer. This raises several big questions:

1) How do you know that the engineer's knowledge of the "correct" answer isn't being subtly encoded in the prompt? Essentially the Clever Hans phenomenon.

2) If you want this to be a fair game, how do you give precisely the same kind of advantage to whatever you're benchmarking the LLM against?

3) Last but not least, if you're not going to throw in your prompt engineer for free with the product, will your results be reproducible by your customers?

To be clear, I don't think there's some cosmically objective way of doing this. If you're using prompts written for humans, you're already putting the computer at a disadvantage. But at the very least, you're measuring something meaningful: how will the model behave in the real world.

I don't find this argument persuasive. If you need to engineer the prompt in order for the model to give you the answer you want, and if it's performing poorly without that kind of assistance from a human who understands the task and the desired outcome... then it's perfectly OK to not bother and give the LLM a low mark on a benchmark. After all, the whole point was to test the LLM's language and reasoning skills.

"Prompt engineering" makes sense if your goal is more utilitarian, but it's not a license to cheat on tests. If you want a machine learning model to generate aesthetically pleasing images, or to follow certain rules in a conversation, then it's OK to rely on hacky solutions to get there.

Acetaminophen has a narrow therapeutic index and can cause severe and irreversible liver injury in doses around 10 g. A single tablet usually contains 500 mg, but because it's a component of so many other "combo" cold meds, including some syrups, it's easy for people to overdose while mixing OTC products to get over a flu.

Aspirin has a lower standard dose (325 mg), higher LD50 (probably around 20-25 g), and is generally safer. It has fallen out of favor because it's known to cause an exceedingly rare but deadly syndrome in a tiny percentage of children, and because it can have gastroenterological side effects.

Ibuprofen is probably the safest option? I'm sure it can be overdosed, but it almost never happens, whereas acetaminophen results in tons of hospitalizations every year.

In theory, no. But in theory, we weren't supposed to have the first Fukushima to begin with. A bunch of things went precisely the wrong way.

That said, Fukushima ultimately wasn't bad, especially in terms of atmospheric releases / land contamination. It was scary, but nowhere near many of our worst "conventional" industrial disasters, let alone Chernobyl.

This is being done across the US. For example:

https://www.wapa.gov/newsroom/NewsFeatures/2020/Pages/New-ca...

This is how you do advertising on HN...

The page is a very explicit plug (pun intended?) for their industrial CT products, and it was clearly done for marketing purposes, not because it reveals anything interesting. It is an apples-to-oranges comparison of several cables, basically showing that they're doing what they're supposed to and are constructed as expected. It was even submitted by an account that is clearly tied to the company.

I'm not upset with them - I think it's a better ad than most - but it's a pretty solid case study of how clever "covert" marketing is being done.

It started as a program where you had to pay the state a pile of cash to have them carry out a number of tests, like repeatedly dropping the gun to see if it goes off on its own. They kept adding stuff, culminating in microstamping requirements that no manufacturer could or wanted to comply with - so only a small subset of pre-2007 semi-auto pistols could continue to be sold.

No, I read that part, but they're still small gripes. He has no objections to the idea itself, and no reservations about the overall design. He gripes about syntax. Let me be clear: I think the crux of his feedback is solid and is a matter of good engineering. It's good to upkeep these principles for the Linux kernel. But it is very much "fix it up and come back".

It strikes me as a weird argument. This is your work. You presumably did your best. If another person calls that work "complete nonsense" or "totally illogical", they are implicitly saying that you failed at basic cognitive skills and produced complete garbage.

Which, you know, might be justified every now and then, but it's not justified in this case.

My favorite part is that California has a roster of handguns approved for sale. The pretext for its existence is consumer safety (it is entirely separate from bans on stuff like assault weapons or large magazines), but the actual effect is that you have a very limited selection in stores, and most of the designs are very dated.

But if you're a police officer? You get an exemption! Apparently, the state has no regard for your safety as a consumer, and allows you to buy whatever you want...

The issue isn't directness. The issue is repeatedly taking needless swipes at the author's competency or intent ("worthless", "complete nonsense", "totally illogical"), when Linus' criticisms are really mostly just small (if valid!) gripes about naming conventions and readability.

This is particularly funny because I remember that several years ago, he publicly apologized for being abrasive and promised to get better... but old habits die hard.

He has every right to run the project as he sees fit, but then, people here have every right to be mildly cranky about that too.

It's really hard to meaningfully compare. They're designed for other things.

Most desktop or server CPUs prioritize massive parallelism, which is useful for OSes and multithreaded apps. In contrast, most MCUs have just one single-threaded core. CPUs are expected to run with sophisticated and bulky active cooling, so they reach speeds up to 3-5 GHz; in contrast, MCUs are almost always used without any added cooling and need to be power-efficient, so they seldom venture above 500 MHz. CPUs require external power controllers for dynamic voltage scaling to realize that performance. MCUs are often expected to run off a single supply, often something like "anywhere between 1.8 and 3.3 V". CPUs have a variety of hardware accelerators for operating on gobs of data (e.g., AVX vector instructions). In contrast, the most an MCU is typically expected to do is handle some low-resolution camera, and only some higher-end models have a hardware floating point unit.

Most benchmarks are optimized for desktop tasks too, so you can expect MCUs scores to be two orders of magnitude lower. But that doesn't mean they perform that much worse at the tasks they're intended for.

In situations where you need to do some real-time ML-based image classification, drive a 4K display, and stream H.265 videos, you generally don't reach for a traditional MCU, but for a CPU, with all the extra power supply complexity and thermal management issues this entails.

SoCs blur the line somewhat, because they often combine a CPU core, a graphics card, lots of memory, and a bunch of other things in a single package - making them essentially a fully-fledged computer that can run Linux, but is about as easy to integrate as an MCU. These are still slower than top-of-the-line desktops, but they're in the "one order of magnitude" territory.

As others are saying, "8-bit" doesn't mean 8-bit address space. It refers to the ALU "word" size instead - i.e., how many bits you can add, subtract, multiply, or divide in a single step. (Larger types are possible, you just need to do the operations in steps, just like 64-bit math on 32-bit platforms.)

Even in the 1980s, most 8-bit microcomputers had at least 64 kB memory. Today, many AVR chips will have 145 kB of memory (flash + SRAM + EEPROM), and pretty much arbitrarily more can be installed externally.

It's a pretty interesting question, even if a bit tangential to the article!

Their main advantage is the comparatively low transistor count. The chips can be made cheaply and don't need cutting-edge fabs. This also makes them exceptionally power-efficient and tolerant of a wide range of supply voltages, so they're easier to integrate into many designs.

Just as important, they are far easier to master. Single-cycle instruction execution, single chip-wide clock, simple interfaces to all peripherals. If you don't have an OS to abstract it all away, most of the contemporary 32-bit platforms are a serious pain. Adjusting clock speed on a typical Cortex-M chip requires following a carefully-choreographed sequence of steps, possibly fiddling with flash wait states, various bus clocks, PLLs, and so on. On an 8-bit MCU, you just flip a bit or two.

It's a weird misconception that "8-bit" means antiquated or slow. Modern 8-bit MCUs run at high speeds, have plenty of fast memory, and integrate all kinds of cool on-die peripherals - DACs, ADCs, op-amps, DMA controllers, USB controllers, and so on. And in a good majority of embedded applications, they are enough.

Of course, there's nothing sacred about 8-bit ALUs, so I wouldn't be surprised if 32-bit ALUs eventually take hold in this market segment. But the replacements would need to preserve that "I can learn this in a weekend" property that isn't preserved in most of the high-performance 32-bit chips available today.

It's this slow not because of the MCU, though, but because the author is emulating another architecture in software. It would be fairly sluggish on a PC too.

This is both very impressive in terms of the sheer amount of work that went into that, but also a tiny bit disappointing because it's not really Linux running natively on an 8-bit chip.

I suspect that native Linux is technically doable and would be a lot faster, but would require a lot of fiddling with the kernel, to the point where you'd be rewriting as much as you're keeping. A lot of assembly shims to port, gotta get rid of all the MMU code, etc. AVR chips in particular also also a bit weird because they follow the Harvard architecture - separate addressing for code and data, which is not something the Linux kernel is made for.

FWIW, modern 8-bit MCUs are actually pretty darn fast. They have clocks all the way to 50 MHz or so, single-cycle execution for most opcodes, some have DMA and other cool gizmos on the die. They are orders of magnitude faster than the 8-bit tech we had back in the 1980s.

Contrary to what this press release implies, radiation treatments are focused too. The basic idea is that you use a rotating beam source with a center of rotation at the exact spot you want to treat. The beam delivers only a fairly modest dose to most of the surrounding issues because of its continual motion, but it always passes through the center, so the cumulative dose in that area is far higher. This image illustrates the idea:

https://patients.uroweb.org/wp-content/uploads/2018/12/Radia...

It's not perfect, and acoustic waves should have fewer side effects, but we already have the ability to selectively target a specific location inside your body.

Many folks here describe this as a solution to what they see as inadequate traffic enforcement, especially post-COVID. But does this mean we're going to claw back the traffic enforcement headcount from police departments? If they're not doing traffic enforcement and aren't too keen at going after property crime, what are the taxpayers really paying for?

The US is vast and many of the attractive rural lands effectively have no law enforcement presence of any sort.

That said, the parent is being a bit too pessimistic. There's plenty of negligibly-policed and freely-accessible BLM land in the West that generally doesn't get abused all that much.

But in part because of the abundance of BLM land - the government owns nearly 50% of the Western states! - we don't really need to allow people to trespass on private land to recreate. There are some exceptions to that - mostly around access to water and beaches - but if you just want to go on a scenic hike, you're not out of options around here, and I'm not sure it's useful to hold Sweden as a role model.

As a private landowner, I'm thankful that I can post a "do not trespass" sign. Even well-behaved hikers leave a mark over time. Some trash is inevitably left behind or carried away by wind. Soil erosion is a problem on frequently-accessed trails. And that's before we get to the occasional drunk or rowdy group.

I'm surprised that you draw a sharp distinction between C and Pascal syntax. They have a shared lineage and are really very close to each other. Yeah, curly braces won over "begin" and "end", but that's not a matter of some huge conceptual rift, just convenience.

There are numerous languages today, including Haskell and Ocaml, that are far more removed from the Algol lineage than these two. Heck, the differences between Rust and C are probably more pronounced than between C and Pascal.

The relative scarcity of castle sieges doesn't mean they weren't a major concern. It's quite likely that castles served as an effective "siege deterrent". That is, sieges weren't common specifically because the likelihood of success was low.

Isn't this a bit of a no-op for Lenovo specifically? I've been using Lenovo-made laptops for years, and never had trouble with DIY repairs - replacing keyboards, screens, batteries, adding RAM, etc. Their devices are pretty modular and DIY-friendly.

I wish they made charging plugs easier to replace, as these inevitably get damaged after 1-2 years, but that's really the only complaint I can think of. Is the situation different for other device types, or are they just trying to score an easy (if deserved) PR win?