grandinj

The article does not make a big enough deal of another saving for the utility - it means that when snow takes out lines, they have more time to deal with the problems before customers start complaining. That can be quite significant if the utility can wait 12 hours for storms to pass, then fixing things becomes significantly easier.

Maybe that is because you are the one not listening.

You even note the problems, but then wave them away saying that "the government could fix them."

So have the government fix those problematic regulations first, and then the AI centres can re-apply for permission.

One option is to stick a mini-UPS in-between the wall the devices. Such a thing is internally a handful of lithium cells and some DC outputs.

For powering a handful of things that consume less than 100W they are quite useful because they typically provide 2 or 3 DC outputs, and replace between 2 and 4 power bricks.

They also provide an hour or two of backup, quite useful in my country where the power sometimes goes out for a bit.

The downside is that I cant find decent ones in my country, and so I end up replacing mine every 2-3 years.

Yeah, as someone who had to implement a protocol stack to talk to a X.400 server, it was not fun at all. Weird encodings, monster spec, all sorts of weird server-specific stuff that you had to do exactly right if you wanted the server to accept your email.

Compared to that, when I implemented RFC821/822 (i.e. SMTP) mail, the hardest part was the weird line-encodings, but other than that, the spec was ___so___ nicely readable and pragmatic.

So this is basically Pick (https://en.wikipedia.org/wiki/Pick_operating_system) for the modern world. Which is a good thing, its about time we resurrected this idea. I wish them the best.

In a comment he says he is doing it for some research into a related thing (somethiing to do with GaN sheets?)

I was there, reading the ipv6 mailing list eagerly. Address space exhaustion was a smaller problem because NAT was pretty primitive, so called carrier grade NAT was not even a thing yet. But cisco had the largest routers and their biggest was not big enough for the core router fabrics projected growth. And there was not enough demand (yet) for very large routers fir cisco to want to design and build the nevessary chips. The IPv6 people thought they held all the cards and could mandate whatever they wanted.

But of course, it was s very long time ago and my memory may be inexact.

A couple of years later ipv6 became unnecessary. A big driver for ipv6 at the time was routers not being able to manage the increasing size of the core routingtable. Then 2 years later betterhardware and routing table compression became available and ipv6 became unnecessary.

Just get some clear nailpolish and apply it with the included brush. Not as good but dead easy.

Collabora was unhappy about the LOOL revival, but not enough to leave.

It was only when TDF contrived reasons to expel Collabora people that Collabora decided to leave.

(Full Disclosure: I am one of the Collabora people expelled)

I suspect that Time Machine is no longer used by a sufficiently large % of their customer base for them to care, and they are slowly sunsetting it. They are quite aggressive about that sort of thing, so I expect it to to deprecated in favour of iCloud soon.

motors do not like the impact loads that wheels see, which is why bicycles with hub motors do not have a long lifespan

Or.... smoking may be indicative of people from poorer backgrounds, where health is generally lower. (cant say for sure, but thats the case where I am from)

Statistics 101: Correlation is not causation.

Unfunded pension and health care

That is a pity. Clearly we need some kind of

   Home For Abandoned Code

:-)

Is this not what the Linux Foundation was about at one stage?

Taking ownership of unmaintained projects so that at least they have the bare minimum of patches being applied, CI/CD running, releases being created?

There is a Chinese player that has taken effective control of various internet-related entities in the Seychelles. Various ongoing court-cases currently.

So the seychelles traffic is likely really disguised chinese traffic.

If you repair it yourself, you have more flexibility in terms of replacing spares with newer items i.e. replacing a whole module when it a part of that module becomes hard to come by.

Internal documentation ..... hmmmm.... LOL.... Often not, word of mouth is the rule.

If there is internal documentation, it's generally pretty rough. Getting it to the point where you can hand it to external parties is a lot of work.

Sadly the US military (like a lot of militaries) are in love with custom requirements. And there is very little leeway for negotiating them out. So unnecessarily custom solutions are the norm.

It was muuuch cheaper that way.

Because adding in repair stuff requires the supplier to provide documentation, frequently training, a parts manifest, guaranteed 10-20 year availability of spares, and probably about 50 other requirements I don't know about.

All of which add up to a rather large contract cost increase.

Possibly this boondoggle will result in the military putting in more reasonable "right to repair" terms in the contract, rather than insisting on the gold-plated thing I mention above, but more likely it will simply result in more cost overruns.

If you have specific performance issues and are able to share the associated documents, please log them at https://bugs.documentfoundation.org/.

Of course, we cannot always help, sometimes the slowdown is due to increased feature or stability or conformance, but often we can improve things greatly.

There is ongoing bugfixing in this area. If you are able to supply the documents associated with broken workflows in this area, it would be helpful to log bugs in our bugtracker at https://bugs.documentfoundation.org/.

Even better would be if your company could sponsor some fixes, of course :-)

Wonderful tool. Has been incredibly useful in optimising LibreOffice.

Sounds like an opportunity to get an inland lake!

this might trick the heuristics in the right direction ie. feed the GPU a bunch of small tasks (i.e. with a small number of samples) instead of big tasks.

This article starts by saying "we dont know what actually happened here, or why" and then goes on to make various insinuations and suppositions, and then proposes policy based on that.

This not useful. More data is required.

Does that matter? Most of the time you will be limited by the network tower and the number of people around you using phones. Energy efficiency is more important to most heavy mobile data users, I would guess

Hmmm. Seems to me they took on a little too much technical risk at the start of an already complex project, to wit, buying into Rust on the kernel side.

Rust in the linux kernel was always going to be a long game. You don't want to have that be a blocker when you really want is to make larger kernel changes.

There is a guy (Patrick Luby) slowly chewing his way through the weirder mac issues and he seems to be making progress, so things are getting better (slowly)

So basically, as long as you are large enough to have direct contact with the upstream team, have a separate team to manage React Native itself, and have two separate teams for iOS and Android to manage stuff that needs native access, you are good.