da_chicken

Yes, and in the days of major supply chain attacks and state-sponsored near catastrophes like xz, "it's probably good enough" starts to look incredibly naive.

Linus's "what matters is distribution" comment also doesn't make sense when merge effectively is distribute. Which, again, is the reality of supply chain.

I live about 90 minutes north of Lansing in a town at about the same latitude as Toronto. Weather-wise, the problem isn't the ice. It's the snow accumulation, the cold. For about 3 months out of the year, you're lucky if it's at -7 C or higher.

It's also just that nothing is structured for it. Homes are built relatively far away from businesses and shops due to zoning, and stroads are the common way to get between the two. And where the stroads end, rural roads begin. It's structured not to be walkable not just at the large city level, but at the small city and town level, too. Our infrastructure is dictated by what the people in the 1940s thought, and they were extremely wrong about a great many things.

It's a local newspaper. It's not in English because it's seeking an international audience.

But, MSC is easy enough to determine from context, and ROTC would be a familiar abbreviation for any American.

Every generation is full of people that have a strong aversion to tech. The mistake was thinking it would magically only be the Boomers with that problem, but I've always known people in my age group who needed that remedial tech class in college.

It did appear to improve for a little while when everyone needed a laptop or desktop to access the Internet. But smartphones have eliminated that. So have tablets. And lightweight laptops like Chromebooks have further eliminated the need for tech knowledge. I work at a K-12 school, and a surprisingly large number of young parents have access to the Internet only through their smartphones. And, truthfully, they don't need a PC to access the Internet anymore. It's an extra cost you can just bypass, and nobody under 30 with kids has spare money at this point.

But, in as much as new teachers coming into our district today are often just as tech-illiterate as those we saw 20 years ago, we haven't seen the number of tech-savvy people really decreasing, either. Tech remains a hobby for some people, and that doesn't seem to be decreasing.

Yes, we're not going to raise another generation where the techies have a common background of making MS-DOS boot disks; reading modem initialization strings; upgrading RAM requiring a chip puller or piggybacking; managing IRQs, memory addresses, or bus addressing for ISA/IDE hardware with jumpers or DIP switches; or knowing what `LOAD"*",8,1` means. But that doesn't mean people aren't learning tech, having fun with it, or making careers out of it.

Not really. The LLM is the data model. The part doing the language manipulation. An agent is the combination of an LLM with an interface it knows how to use to take actions with, though it may just refer to the interface or connection or tool itself.

The LLM itself is primarily a transformer that handles tokenization, mapping, and neural-network reasoning (in simple terms). It's the engine. It takes in language, interprets it's meaning, and based on other language that supplies instructions, decides how to respond. The agent typically takes the form of an instruction for how to use a tool, combined with how to access it.

Technically, the chat session is itself an agentic tool because it's taking input and returning output through that interface. But it's kind of the default tool. Stdout, if you will.

Say you're in Gmail and you get a message that tells you about a meeting, but doesn't include an invite. If you tell Gemini to add an event for that meeting to your calendar, the LLM interprets your instruction, then uses an agent tool to read your email, interprets it, and then uses another agent tool to create a meeting on your Google Calendar.

Your opinion on the BOM isn't wrong, but it's also not germaine to whether or not you're actually following the spec. The spec is the spec. If you don't like it you can get the spec changed. You don't get to ignore the spec and then claim support. That's not how standards work. "I don't like it," isn't a good explanation.

Otherwise I'd be inclined to fix the spelling error in the HTTP referrer.

Yes, I agree.

It's more common for programs that say they support UTF-8 to not really do so at all. It wasn't that long ago that "UTF-8" support was often just single byte, so it was little more than ASCII. Even now it's common for programs to choke on the optional BOM. Yes, it is redundant, congratulations. The spec still explicitly allows it. Three and four byte character support is still not the best, too.

Oh, does that mean I get to say you're ironic because, literally, they didn't tell anyone to do anything. They said they didn't understand the worth of the opinion. You're interpretation is selectively literal in order to be rhetorical.

Does that mean someone else gets say I'm being ironic because I'm selectively literal in order to be rhetorical? Well, okay, I guess it's harder now.

I have definitely seen job postings that were so detailed and narrow that they couldn't possibly find anyone "qualified". They were clearly making it so that it would be easier to claim that nobody in the country was qualified.

But I will say that the only people I have met that are here on H1-B have been uniquely qualified for their position. Such as, they invented a way to scale a given chemical manufacturing process, and they were developing it further.

But I got the impression that they were not particularly well paid like I would expect an American in the same position to be.

The same as every publicly held company. The shareholder.

What else did you think the Friedman doctrine meant?

Google is an overwhelming market leader vertically and horizontally. Not only do they not have to compete with their competition. They don't have to compete for their competition's business partners. They don't have to compete at all.

What's more, they're a publicly traded company. That means their primary product is no longer what they sell. Their primary product is stock dividends. That is their primary business now. Whether you're buying a service or a product from Google, you're no longer their true customer.

They treat such customers like they don't matter because they don't. And until they stop being in such a position of dominance, or someone magically transforms the whole of American business culture it won't change.

Amongst all this rhetorical brush-beating, what were you trying to teach the snakes?

I think it was obviously intentional because they haven't accepted the solution yet.

The purpose is to announce that they are aware of the claims of a solution, not to announce that a solution has been accepted. They're waiting on the required two year timeline before announcing whether or not the solution is accepted. Their writing reflects that they are explicitly NOT accepting a solution until then.

Okay, I don't really feel like your going for a good faith interpretation of the points I'm trying to make. You're taking things hyper literally and out of context. I don't feel like you're really trying to understand what I'm saying at all.

You're mistaking shitty software for software that doesn't work. Shitty software is 100% functional. You just hate it.

By intentionally picking the software that eliminates the UI, when the whole benefit of computers as a tool is that the UI is infinitely flexible, you're picking shitty software that doesn't appear that shitty. But it still is.

I mean, I hate the way my TV remote works and have wanted to change it. But I can't. It has buttons that open NetFlix or Apple TV that I can't change, and I don't have any ability to reprogram them because the companies paid for it to be a permanent advertisement I can't get rid of. That sucks.

But also, I think we only have to look far for what shitty appliance software looks like. VCRs and microwaves are notorious for having shitty software. As soon as we introduce a network, suddenly the software sucking is an immediate problem: witness the nightmare stories of Jeep updates, Tesla lockouts, and paywall feature locks when the hardware is present. Or we can look at the spying done by LG that you can't turn off. Or the forced advertising that Samsung showed they can do to your fridge.

Or how automobiles need an OBD reader even thought they ship with a built-in tablet. Or how the OBD codes are something you have to pay for. Or how you might not be able to disable the stupid "shut the car off" feature when you stop at a red light.

Shitty software on microcontrollers is some of the most tyrannical shitty software there is.

In my experience, this is the only kind of software that ends up not sucking. If development is not driven by users in a very intimate way -- like being one and the same person -- then you routinely end up with necessary features only half working or splitting essential information across multiple screens or dialogs. Eating your own dog food is essential to rising above that, because only that reality will overwhelm the developers sense of the "proper" way to do things.

I believe it's the major reason that industry specific information systems are universally shitty. The user can't articulate what they need to accomplish and the developer doesn't really understand the purpose or importance of the work. Result is bad functioning or bad interface.

It's why only software like text editors and web browsers gets to be really good. Huge user base. Lots of developers involved.

Git kinda proves that it's not infallible, though.

I'm a native speaker and I agree. "Ought" can connote an obligation or responsibility of some sort. "Should" is used more often when the outcome is out of any control. It might only be the speaker's belief.

But there is significant overlap.

I think it originates with the early web. JSON being a replacement for XML, and "document" being the general description for the response to a web server.

> If they want to train an AI they should pay for it like everyone else.

They're paying for electricity and taking data without paying for it. It seems to me that they're paying for it exactly the same way everyone else in AI did.

I think when people are complaining about Captcha they're complaining about yet another "pick 6-20 pictures of traffic lights/school busses/stairs/stop signs/bicycles."

> Regarding 'minor source', in this case the expected additional premature deaths in the research range from 3.4 to 6.5 annually. [1] At the same time, air pollution leads to about 100,000 deaths a year in the US. While tragic at an individual level, adding 0.006% to the annual premature death count is fairly minor, just as reducing the deaths to 999,994 would be considered a pretty minor fix to the issue.

I just love the irony of being absurdly callous and dismissive of human life while also getting the basic math wrong.

Nevermind that the 100,000 figure is across the nation of 300 million and includes things like automotive exhaust, while the other number is likely to be borne by that one specific community. Indeed, if you look at the study[0] your article cites -- which is looking at what we should be working on reducing -- industrial deaths are under 30,000, and electrical are around 10,000. So below half of your figure.

[0]: https://pubs.acs.org/estlcu/article/7/9/639/504911/Reducing-...

I mean... yes.

Blacksmiths, wheelwrights, and wainwrights transitioned to auto mechanic or carpentry work. Not all of them, but for most the skills were portable. Several of the carriage-making businesses transitioned to automobiles. Studebaker and Oakland (which became Pontiac), for example. I'm sure the most experienced people lost big, of course, and we shouldn't minimize the damage done to people's livlihoods.

Unless you mean taxicab drivers, which was the term for them before the automobile. Taxicab = taximeter cabriolet, and a cabriolet is a style of horse-drawn carriage.

It really was the horse people that lost out the most. That's why the idiomatic reference is for buggy whips, not so much for buggies themselves.

You still likely need a human bypass. "I was injured or disfigured so my face no longer anything for you to compare to. I do not now, and never shall again resemble the image in the system."

Similar things happen when you require fingerprints or retinal scans. "Well, I don't have a right hand anymore. It's in some hospital's incinerator."

And not having an override or bypass is a software issue. Designing a system that doesn't permit exceptions or overrides is bad software design.

It doesn't really change Euler's formula. It just adds a factor for x to it (or an additional term to hide inside sin and cos as functions). That's less convenient, not less true.

However, I don't really see a benefit gained out of doing this to keep your theta between -1 and 1 instead of between -2pi and 2pi. Like it's not a difficult thing to estimate or convert in your head to get a close enough estimation.

In Windows 9x (95/98/ME) the swap file could expand indefinitely, with no mechanism to limit its size.

Under Windows NT 4.0, Win2k, or WinXP and on, the page file has a built-in size limit that you can set. You can indirectly force that minimum size to increase if you enable full memory dump capture in the event of a crash (it must be larger than main memory to do that) and that was really easy to do so I think a lot of people made that mistake. Even on the modern Windows, if you have a crash then the system will automatically enable full memory dumps for the next 4 weeks hoping to be able to debug the second crash. That can also result in the minimum size increasing beyond the maximum you set, but in neither case does it grow indefinitely.

Eventually the OS will start returning an error that it's out of memory or out of virtual memory. But if the application you're running can handle that gracefully, then it may not even crash.

I think Windows is sluggish now in part because it's about 5 or 6 layers of abstractions piled on top of each other between the application and the hardware, and also because Microsoft keeps jamming services and side projects onto you. It's been a long time since Microsoft has adopted the "shut up and get out of the user's way" approach to OS design. Now it loves to distract you from the program you're working in.

It was always like that.

It's due in part to the number of people that kept posting screenshots of their code in their question, and the number of people that couldn't search to save their life. The noise ratio on incoming questions was always ridiculous, and the number of people who don't know how to ask a technical question is staggering. I do wish they had started to ask a series of questions to people for their first 5 or 10 posts to force them to ask questions in a useful way that was conducive to getting answers. The whole site never got over being hostile to new users.

SO had a number of fundamental issues. If you found a duplicate and flagged it as such, you couldn't explain why you thought it was a dupe in the flag. This meant that "this is a different question but the answer is the same" was just tagged a dupe the same way "this is literally the identical question" was.

I stopped participating entirely after a single event. When I was moderating the moderation, and the site decided to give me a trick question to "test if I was paying attention". Yeah, no. I don't have time for that bullshit. Apparently I'm still a top 1% user, though, and I think I've gained another 8,000 or 9,000 points since I left and stopped answering at anything.

Windows does freeze and become unstable, but it's usually because of some ring 0 errors not getting trapped appropriately.

But Windows has always handled both OOM and out of disk space very well. The system will be extremely sluggish, but it typically continues operating.

The Linux design is to keep using memory, then push to swap, and then when you OOM you hard lock. The built in kernel OOM module can miss when RAM usage spikes rapidly. You can enable OOM monitors like systemd-oomd or earlyoom, but they do not run by default, and their behavior is to term the offending process.

The thing about Windows is that when you request memory, you're only granted memory if it can be guaranteed in the first place. The application will get a "not enough memory" error. On Linux, you're permitted to request more memory than the system actually has, with the idea that you won't actually use that much memory. It's optimistic that way. But if you do use it, then you're screwed.

My assumption was that it was written by several separate prompts and then stitched together.

I don't find that sentence confusing, but I definitely found the article poorly written. Here's the sixth nearly identical map and now let's repeat the exact same thing already stated five times or more while including one new sentence of detail. The density of actual information in the writing is so low that it's hard to follow.

The article is so repetitive and padded out with empty prose that I found myself ignoring whole paragraphs. It's like the author decided to describe what an el niño is, then describe what an el niño is, then describe a super el niño, then describe what an el niño is, then describe what an el niño is, then describe what an el niño is, then describe the possible consequences of a super el niño, then describe what an el niño is, then describe what an el niño is, and finally describe what an el niño is.

According to the documentation, CPU requests don't cap usage. They're not used for that. They're used to gauge how much CPU you say you will use. They're used for allocation and pod assignment. They never throttle you. They never cap you. According to the documentation, CPU limits are the only mechanism to prevent exceeding your resource allocation. You directly said the opposite of that. If that's not what they actually do, then FIX. THE. FUCKING. DOCUMENTATION. Either the documentation is wrong or incomplete, or you are wrong or incomplete.

That's the contradiction. And, to be clear, I think you're both wrong and incomplete.

It's partially a problem that how it's being documented is either really misleading or fundamentally incomplete. That may be because that's just not how Google imagined Kubernates was going to be used. If you need to understand the CPU scheduler to be able to use this option in the first place, then the documentation should explain that directly or by referring to more information elsewhere.