Neither Intel nor AMD have a packaging plant for CPUs in the US. Similarly, I don't think there's a packaging plant in the US for discrete semiconductor components like diodes, bipolar transistors and power-mosfets. The parts might be US designed, even diffused in the US, but for being "Made in America" they need to be packaged in the US also.

I think that's a show-stopper for his idea.

Professors should create high-quality teaching material and teach their students well. I don't care what tools they use. They can copy from textbooks, reuse material from other professors or use a LLM - or even do it all by themselves.

My professor in theoretical physics did his classes by memory - deriving all the math live on chalk-board. Didn't give a single handout ever. Impressive and I learnt a lot that way. My materials science professor used a textbook, talked and explained that book with a few excourses left and right. Great course.

None of those guys was sloppy, though.

So instead of paying for a dramatic reading of a book with all the nuances of the narrator's interpretation of the book we will get a monotone unreflected drawl of a reading. This assumes people only pay for audiobooks because they're too lazy to read.

I hope people will return those AI audiobooks. That may be the only way Amazon might learn.

That's correct. But in that case they would have needed to inform all customers at the time the purchase was effective. Instead they decided to continue service and by that demonstrating concludently that they honor the liabilities of the previous owner. You can't dump your own lazyness on your customers.

In my country, chances are pretty solid that any court will agree that you still have a lifetime contract with them. And any competitor can actually sent you binding cease-and-desist letters to stop that uncompetitive procedure.

From FTA:

>In-office requirements will not be left up to managers, Dimon said.
>
>“There is no chance that I will leave it up to managers,” he said. “Zero chance. The abuse that took place is extraordinary.”

Well, from my experience people can drift off in in-person meetings as easily. Especially the "important" people prefer typing and reading on their laptop to listening to the meeting.

He's such a smartass. Makes me wonder how he got there.

If you would actually *use* their service you would know that CF does not block much unless you specifically configure them to do so.

That's the beaut of their service, they allow you to control who can visit your domains and who cannot.

They're not without blame, but I would actually consider them to be sensible good guys in this snake pit that we call the web.

I am using Manjaro as my daily driver. It's Arch dialed down to a less bothersome level. It just works. They even made the AUR more easily usable. Props to them for that!

That said, I've realized that I would probably also be happy with plain Debian. Being on the cutting-edge isn't so important for me nowadays.

But the real question here is,... is America safer if Russia successfully invades the Ukraine. Or is it safer if Putin gets stuck in this mess and keeps bloodying his nose. If you say yes to the former, then you have all the reason to complain. If you agree with the latter, then it's money well spent.

Magnitude 4.5 is not dark. It should be easily visible from a suburb sky - just don't try to find the comet standing right next to a streetlight.

Light pollution is bad as it is, but at least in my area 80% is darker than 4m5. Now, true 7m skies... that would be a treat, but nobody in central europe is ever going to have that anymore.

The trouble is that in server workloads you generally don't see ONE LARGE I/O operation - lots of small ones instead. There are very very few server workloads that involve transferring >100MB data at a time (even when it comes to DB snapshoting).

There's lots of server workloads that involve large IO requests:

  - backups
  - DB startup/shutdown
  - DB traffic that generates or reads a lot of new data (say report generation)
  - HPC workloads that work with huge data sets
  - animation farms that work with huge images/movies
  - web servers streaming out big files
  - fsck
  - virtual desktop servers where the desktops are virtual instances running on the server. There any IO load within that 'desktop' runs on the server.

etc. As there is a fair number of server workloads that are IO heavy but which use small IO requests.

On the desktop this is common (all your AVI files).

If you have those big files in networked storage or if you are backing them up to some network host then you've already transformed those kinds of IO requests into big IO requests on the server side as well: the big file you read or write on the desktop the network file/backup server will read/write from its own disks, etc.

Really, "interactivity sucks during big IO" kind of bugs can hurt servers just as much as they can hurt desktops. The boundary between desktops and servers is very fluid.

Yeah, that's what the discussion was about - we improved that particular case, see this commit (which can be found in v2.6.36), and Phoronix reported about that upstream fix.

Thanks,

Ingo

There's also the VM fix from Wu Fengguang, included in v2.6.36, which addresses similar "slowdown while copying large amounts of data" bugs.

There were about a dozen kernel bugs causing similar symptoms, which we fixed over the course of several kernel releases. They were almost evenly spread out between filesystem code, the VM and the IO scheduler. And yes, i agree that it took too long to acknowledge and address them - these problems have been going on for several years. It's a serious kernel development process failure.

If anyone here still experiences bad desktop stalls while handling big files with v2.6.36 too then we'd appreciate a quick bug report sent to linux-kernel@vger.kernel.org.

Thanks,

Ingo

So I know some people may read this and think "haha, funny joke" but given that most users are extremely predictable regarding what programs they use and when and how they use them (same with web browsing), shouldnt it be possible to gather user activity over time and analyze it to help improve scheduling.

Yeah, that's certainly a possibility.

This is also the goal of most heuristics in the kernel: to figure out a hidden piece of information that the application (and user) has not passed to the kernel explicitly.

The problem comes when the kernel gets it wrong - the kernel and applications can easily get into a feedback loop / arms race of who knows how to trick the other one into doing what the app writer (or kernel writer) thinks is best. In such cases we get the worst of both worlds: we get the bad case and we get the cost of heuristics.

(Heuristic and predictive systems also tend to be complex and hard to analyze: you can rarely reproduce bugs without having the exact same filesystem layout and usage pattern as the user experienced, etc.)

What we found is that in terms of default behavior it's a bit better to keep things simple and predictable/deterministic and then give apps the way to inject extra information into the kernel. We have the fadvise/madvise calls which can be used with the POSIX_FADV_DONTNEED flag to drop cached content from the page cache.

Heuristics and predictive techniques are done when we can be reasonably sure that we get the decisions right: for example there's a piece of fairly advanced code in the Linux page cache trying to figure out whether to pre-fetch data or not.

The large file copy interactivity problems some have mentioned here were most likely real kernel bugs (in the filesystem, IO scheduling and VM subsystems) and were hopefully fixed in the v2.6.33 - v2.6.36 timeframe.

If you can still reproduce any such problems then please report them to linux-kernel@vger.kernel.org so we can fix it ASAP.

In any case, we could all be wrong about it, so if you have a good implementation of more aggressive predictive algorithms i'm sure a lot of people would try them out - me included. We kernel developers want a better desktop just as much as you want it.

I see that the bug entry you referred to contains measurements from early 2010, at which point Ubuntu was using v2.6.31-ish kernels IIRC. (and that's the kernel version that is being referred to in the bug entry as well.)

A lot of work has gone into this area in the past 1-2 years, and v2.6.33 is the first kernel version where you should see the improvements. Slashdot reported on that controversy as well.

If you can still reproduce interactivity problems during large file copies with CFQ on v2.6.36 (and it goes away when you switch the IO scheduler to deadline), please report it to linux-kernel@vger.kernel.org so that it can be fixed ASAP. (You can also mail me directly, i'll forward it to the right list and people.)

Thanks,

Ingo

Yes i agree with you that if a 45 msecs latency happens on every frame then that will snowball and will thoroughly ruin game interactivity - but note the specific context here:

you can see the commit referenced by Phoronix here

(hm, my first link above was broken, sorry about that.)

Those 45 msec delays were statistical-max outliners - with the average latency at 7.3 msecs. This got cut down to 25 msecs / 6.6 msecs respectively via the patch. Note that it's also a specific, CPU overloaded workload that was measured here, so not typical of the desktop unless you are a developer running make -j build jobs.

We care about optimizing maximum latencies because those are what can cause occasional hickups on the desktop - a lagging mouse pointer - or some other non-smooth visual artifact.

Thanks,

Ingo