Posts by Henry Wertz 1

Greasy

Moving attachments from Outlook storage to Onedrive? Confusing and a blatant cash grab.

Blocking *all* E-Mail (including ones without attachments) until the Onedrive space is freed up? Greasy and sleezy.

Sure...

Sure, trust us...

So, everything they say is true, to some extent...

1) You won't get the same results from one run to the next (probably, since there will be other users on the system.)

2) They'll upgrade hardware from time to time.

But... obviously (as others have pointed out) you can run benchmarks anyway and get a general idea of performance.

From running Linux and Windows VMs myself (locally), Windows straight-up generates an insane amount of disk I/O, like 10-100x the amount a Linux VM would; my suspicion is you get access to the amount of CPU power you are supposed to but the storage system is being absolutely hammered and so the disk latency is high.

I note here, Amazon has setups where the SLA allows for up to a *15 second* latency on storage access! Not that it's usually anywhere near that high, but getting like 14.9 second latency on your disk access would needless to say result in poor performance, but Amazon would be able to say "Welp, it's within SLA so it's working as intended."

Network isolation

Network isolation....

I'd just like to point out, after the demo of remote starting, dicking around with brakes, and enabling/disabling power steering, etc. on a Jeep via Onstar, that at least some car companies have seperated their CAN busses to some extent. (The Onstar had access at all because one of the features is to notify you, and a repair place if you want, if your car sets any check engine light codes; and you can (why you'd want to, I don't know?) check your fuel level remotely.) Previously the Onstar module was relied on to behave itself and was directly on the (single) CAN bus; after that incident, it is isolated and only requests it's supposed to be able to make are let through. How much isolation is there? Would the headlight be isolated from the remote key receiver? That I don't know (other than on Toyota RAV4s where clearly the answer is "no".)

Ubuntu time!

I ran Ubuntu on an ARM Chromebook (Acer Aspire) with a Tegra K1 2 or 3 years back... a quad-core 2.2ghz ARM (with "big.little" so it had a 5th like 1ghz core to run on when it wasn't totally idle but didn't have much to do). 22 hour battery life, over 12 hours if I ran video encodes on it (which ran pretty quickly). Ubuntu ran totally normal (the Nvidia driver on there even had CUDA support), and Ubuntu (like most ARM-supporting distros) has virtually every package available on ARM as it does on x86-64. I was running a regular, full Ubuntu desktop, firefox, chromium, libreoffice, video encoder and playback, etc.

I put on qemu-user-x86 and qemu-user-x86_64 and (since Debian supports "multilib") installed the base 32-bit and 64-bit x86/x86-64 libraries so things would run. It only got about 10-20% speed -- BUT, again, since almost everything is available in Linux ARM-native all I ran under emulation was 1 "binary blob" printer driver (which used more CPU time than on native x86 but still generated pages faster than the printer could print them, so no real harm); and some Android Studio binaries (... I'd run a build that took like 20 minutes to run on the previous system I had, with about 2 seconds of it being native x86-64 binaries, the rest ran under Java; on the ARM it took about 5-10 minutes with about 20 seconds of it being the same x86-64 binaries.) I tried running wine, it worked for simple apps but qemu didn't handle threading right (due to ARM not having strong memory ordering guarantees between processors and qemu not handling that.)

Now? There's apps called box86 (32-bit) and box64 (64-bit) to run x86-64 apps on ARM; and unlike qemu it DOES support multithreading, and does not require all sorts of x86/x86-64 libs to be installed; apparently supporting OpenGL and Vulkan including running games under wine. And several of the apps that DIDN'T exist for Linux on ARM yet a few years ago now do. (For exmample Android Studio now has native ARM builds) (Edit: to be clear, I'm talking about running x86 & x86-64 apps under Wine; native wine for ARM does support running Windows for ARM apps, if you really want to do that.)

And hardware DRM

Besides needing to take the tractor to a John Deere dealer to even get "check engine light" stle codes read out, they also use DRM (rights restriction chips). Oddly, you can actually get grey market eastern European ECU software and then use free software for diagnosis and buy off the shelf parts. (For example, buy a $70 Bendix fuel injector instead of paying John Deere like $500+ for the same injector with a rights restriction chip on it). Of course John Deere would claim it's black market software, but once you own your tractor you can do whatever the f' you want to it so they can void the warranty but othewise don't get to have a say in it.

The US Gov't passed rules in the mid or late 1970s restricting car companies from this kind of shenanigans (requiring all parts and service to come from the dealership, restricting non-dealerships from getting diagnostic info from the vehicle anjd from getting vehicle service manuals and specs, etc.) For cars that includes that car companies cannot void the warranty for using aftermarket parts (of course they're off the hook if a low quality aftermarket part directly caused whatever you are going in to have repaired, but other than that...) iI don't think anyone back then imagined a tractor company would decide to try the same type of BS.

signing

I suppose one feature this'll add, there's pdf forms where they can be filled out and signed. But not with pdf.js (at least I think not?) As much as I'm not a big fan of Adobe, if you are using Win10 or 11 and worrying about telemetry, well, that ship has sailed. Use Linux if you don't want to have info phoned home.

Talking head

I have never figured out why people will believe anything a clean-cut talking head has to say. But there's a portion of the population that do! (See Fox News, a toxic blend of real info, opinion, and fabrication; but despite it being shown to be an unreliable source of news, since it's said by a news anchor type people believe it hook, line, and sinker.)

Torn

Torn on this. On the one hand, they have a strong position in advertising. On the other hand, facebook, twitter (before musk scared off advertisers), etc. get along fine doing their own ads. Part of the anti-trust act involves companies acting anti-competitively (I.e. Microsoft using their position to gain a monopoly on office software, trying to gain a monopoly on browsers but IE was too crappy, etc., buying all their competitors so you have 4 or 5 lines of Microsoft Dynamics instead of Microsoft and 4 competitors.) Not sure Google is doing this.

What does this mean?

What does it mean to "support the hardware" but not provide software updates even for critical security flaws? Isn't this nonsense and gibberish? Does it mean Cisco will keep billing you for "support" while (since they are not even patching critical flaws) really providing no support? Does it mean there's some kill switch in there, and the thing will fully drop dead in 2025? Does it mean there's some Cisco switch equivalent of DD-WRT* and Cisco will continue to consider the box supported (since they have already abandoned the software, but apparently not the hardware.) (Really I'm taking the piss on this last option, I'm sure Cisco would not permit that to happen.)

*DD-WRT is aftermarket firmware for wireless access points, for those many "consumer" access points where the stock hardware may be fine but the stock firmware can be awful, feature-poor, buggy, and not receive updates for long at all.

Long term AI code

The elephant in the room with AI code generation as well... they are taking your code and code snippets from wherever (github public repos, stackoverflow, etc.), training off that, and the AI essentially can spit out ffragments of code it got from these sites, recombine bits to fit the problem you ask for, etc. So, if these places replace programmers with AI... what happens a few years down the road when new languages and problems come out and the programmers are gone, or used to asking the AI for code and fix it up? The programmer is no longer in practice being able to write their own code, and the AI is not trained to be able to write code either.

(The other elepjant in the room, whar's the legal issue with this system deciding to just verbatim spit out a piece of code? They can claim it trained off it then recreated it all they want, but that's not what it's doing, it's doing a copypasta out of it's memory. To me that means that program is still subject to it's original open source license (or just plain pirated if it's online but copyrighted and not open source.))

one to ignore

I would follow NDA, and even without NDA I would not leak secrets, proprietary info, etc. But a non compete? If you are not paying me you don't get to say what I do with my time, I would thoroughly ignore this.

Fine by me

Fine by me. On the lower end of things, there's all these systems with like 4GB or 8GB or whatever soldered on + 1 DIMM slot, I have 20GB in my system right now (4GB soldered on + 16GB DIMM). I already had the DIMM but if not, I really wouldn't mind getting 4GB+12GB in a case like that and saving a little cash. And 8GB soldered + 24GB would get you a nice 32GB total. It theoretically troubles me that having one DDR4 soldered on means I cannot get that sweet sweet dual-channel speed, in practice I've found this to make little difference on the 2-4 core CPUs that ship in these systems with soldered RAM.

Leaks

I think an important consideration if this is done at scale is what happens if there are water leaks. I'd want to arrange lines and coolers so if they leak, they drip onto the floor instead of into switches, power distribution, etc., you'd want to have it so if liquid did get on the floor there's some way to handle that (which might be just to let it evaporate if it's under a rack, you'd just have to make sure there's no cabling running where it'd get potentially immersed). I'd also like to make sure, if the worst happened and there was an internal leak, that the server or power system would blow a fuse to it rather than having it burn up (if it's not possible to use non-conductive coolant.), and even if the coolant is non-conductive it'd be good to have enough monitoring in the system to quickly isolate leaks (it'd be a rude surprise to find out that some server is running fine since it's non-conductive, but some leaks been dripping for months on it and it's half-full of liquid.)

I haven't heard of people having big issues with liquid cooling on gaming PCs. But, that said, there's a big difference between doing it on one system where the gamer carefully puts it together, and probably has one of those cases with the clear side panel so they can look in and see what's going on... and a datacenter were you'd have 100s and 100s of machines in racks where you can't casually glance inside to see how it looks.

Past problem

One of the problems in the past with this was that many of the designs were breeder reactors. Which is great for operational efficiency but essentially means that the waste is close to being weapons-grade, breeder reactors have effectively been kept off the market for that reason.

Could it be shipping problems?

I'm wondering if part of the problem couldn't be shipping & packaging? Low-tech ICs, those ones with like 10-40 pins, you could probably dump a bunch into a cardboard box, ship them, and it's fine. Do that with more modern chips and they'll probably build up enough static rattling around to fry each other and break off some pins while they're at it.

Also fraud

Also fraud and other charges possible here. In the US warrantys are ONLY offered by the original manufacturer, extended warrantys are also only offered by the original manufacturer. Anything offered aftermarket is an extended service plan and it's a serious federal crime to claim you are providing a warranty for a product you did not manufacture.

A past problem with FCC enforcement was that the FCC regulations allowed these fraudsters to self-report their income and assets, as a fraudster they'd claim they have like $10 and the FCC would be obligated by regulation to allow like $1 a month payments on multimillion dollar fines. My understanding is the FCC recognized this problem and those regs were gutted out and replaced with sensible ones allowing agressive colelction of fines a few years back. (I suppose previous fines are grandfathered into the old useless regs but new fines would not be.) So hopefully if they are not imprisioned as they should be they can at least have their assets seized and be bankrupted for the rest of their lives.

Change in stance

Two big factors in the change of stance:

1) As for the USPS's previous stance on EVs and such, the insistance on using gas and only gas was not based on repairs or anything, the USPS had a nutjob Trump appointee running things; for a nutjob Trump appointee, he was actually relatively competent. He did some sensible route rearrangement (mainly eliminating some air routes that were there just to guarantee 1 day end-to-end service but were not running even close to full, using enormous amounts of fuel to transport those packages compared to ground transport.) But the decision then of gas and only gas, not even looking into hybrids, was just basically a personal opinion and not looking into the actual costs and benefits. Given the postal vehicles constant stop-and-go, there's no way even a real lemon of a hybrid wouldn't come out far ahead in total costs given the huuuuuge fuel savings in the type of driving the postal vehicles do. The existing vehicles get something like 8MPG average due to the "drive 1 block and stop" type of driving they typically see. It's the exact scenario where the hybrid capturing braking and using it to get the vechile moving will result in huuuge MPG increases.

2) For whatever reason, the car companies are looking into ditching even hybrids and going straight to EVs. (I'm surprised they didn't stick with hybrids longer. But OK.) It seems like even a few years ago, you had Tesla, you had Chevy Volt (before it went off the market), and you had some companies making "one offs (not quite, but selling 100s of some vehicle, usually not even 1000.) You now have several car companies claiming they'll go all-electric in the next couple years, electric models from almost every car company (you can get an electric Dodge minivan even), it seems like the technology has really matured. Even 2 or 3 years ago, I would not have advocated for all-electric postal vehicles either, times have changed! They STILL drive some of those postal vehicles they bought in the late 1980s; but since (Other than the chassis!) it's off-the-shelf parts largely, they might not have been able to keep getting parts made for postal vehicles, but the companies will gleefully stock repair parts for a Chevy Cavalier. It's at that point now, there's enough EVs on the market that (unlike even a few years ago) I expect now they could either buy some model, or have it custom built but use some models' drivetrain, and keep being able to get parts for it as needed.

WTF?

WTF? You would hope these firmwares and devices would use some spec (even if proprietary) so fatal errors (even if in this case they are false) could be passed on, or there could be an error that the softwares are non-matching, or failing all that there could be a warning that the RAID card it expects to get some status from, it's getting no status at all from it. Oh well.

Pi4 is fine for now

Supply chain aside, Pi4 is fine for now. Really the specs on it are quite high on it. Even if I built a little desktop out of one the only thing I could imagine is wanting more RAM for some memory-intensive uses (although you can already get one with 8GB on it -- well it's listed at any rate, I can't say if you can actually *get* it...)

Nice!

Nice! I mean, don't get me wrong, it's useless, but I'd get one of these before I got LED strips, LED fans, LED RAM, etc. etc. for my tower. Particularly since, per the discussion of what key switches they are using, they are worrying about the keyfeel and actual functionality as a keyboard (important to me, I'm typing this right now on a Model M keyboard.)

I dabbled

I dabbled with Nix. It's indeed interesting. I found the documentation rather impenetrable, seriously, they need a "get started" guide with practical info on how to get started. But it essentially stores each "package" in /nix/store/(hash string)/, there's a nixpkg package manager that provides nix scripts to actually install regular packages and get something done with them. All build dates/times/etc. that vary between one build and the next are stripped out of the binaries, so you can actually rebuild bins from source and they will have the same checksums as pre-built binaries do. With nix on a normal distro, you have like a /home/user/nix sort of directory, and you add it to your $PATH; with nixos, there's actually only binaries in /nix/store/*, there's just /bin/sh (not even /bin/bash) and /usr/bin/env (so scripts can use "#!/usr/bin/env bash", "#!/usr/bin/env python" to run python, etc.) with all other binaries and libs in the nix store, I haven't run nixos so I don't know if they use bind mounts or symlinks to place these in a conventional layout somehwere, or long $PATH and $LD_LIBRARY_PATH to point to the bins and libs, or what.

The use I saw it for was a build system for building firmware for a product, rather than a set of .debs or a custom build setup in a VM or a linux from scratch config or "here's some specific compiler and stuff, stick them in /opt", they used nix to have the exact compiler etc. they wanted for reproducable build. When they wanted to update the toolchain, they could update their nix script to use them, QA the new firmware and away they go, if not they had the option to trivially flip back to the older toolchain if they wanted.

Closed cooling?

Are they seriously just like running it through the colling system once then like spraying it into the air or what? My cars have all used water cooling, and other than the sh**ty Dodge Shadow I had that ridiculously blew the head gasket, I have not had to keep adding water to any of them. (The Shadow started visibly spraying coolant out the side of the block and also was pissing it away into the cylinders just as fast, which is why I say it blew it ridiculously.) Are they seriously just running water through the cooling system once then dumping it? Highly inefficient, especially if they're using potable water (presumably water treated by the local water treatment plant) for it.

Sensible

Since I'm not too familiar with these terms, I googled it. There's a whole list of instructions newly required by each, but the highlights -- x86-64 is as the name would imply 64-bit x86, SSE and SSE2 already existed then so they can be used. x86-64v2 requires SSE3, SSE4, SSE4.1, and SSE4.2. x86-64v3 requires AVX and AVX2. x86-64v4 requires AVX512 (which I assume won't be that popular to make a minimum given some of Intel's newer chips have removed AVX512... since the power cores supported it until it was disabled through microcode, but the Atom-based efficiency cores did not.)

Sensible. To be honest, video players, encoders, and games generally already do runtime detection of what MMX, SSE, and AVX instructions are supported and uses them or not on the fly. The software defined radio (SDR) stuff I used would generally run a ahead-of-time "calibration" step where it determines which instructions the CPU supports, then does runtime tests on various hand-optimized routines for Fast Fourier Transforms and whatever other number-crunching to determine which routines gave best performance (the run-time test is needed because some CPUs were actually faster running a combo of older instructions than using the newer instructions, for whatever reason.) These are what would get by far the largest speedup from these instructions, and they already use them. Gaining a percentage point or two speed on libreoffice or whatever, while having it not run on the older systems that might get the real benefit from those few percent speedup, is kind of pointless. hwcaps are cool, because you can ship side-by-side libraries (and I think binaries) for any other packages that would actually benefit from it, the system would chose the x86-64 lib if it didn't support certain instructions and the x86-64v2/v3/v4 libs if it does support the required instructions, on the fly. Could make things interesting if there were compiler bugs... but I haven't heard of any distro having a serious problem with that for years and years so I think it'd be smooth sailing.

That said.. my oldest system currently is Ivy Bridge. Having x86-64v3 required would mean I could not run the software (it has AVX but not AVX2.) It supports x86-64 and x86-64v2 though. So it wouldn't affect me. But again I also don't see the benefit given the programs with by far the bulk of the benefit already support using those instructions or not "on the fly".

Side note -- isn't this amusing. Both macOS and Windows have dropped hardware support down to under 5 years (macOS Ventura requires x86-64v3 due to AVX2 usage, and also drops hardware drivers for numerous older hardware, even pre-USB3 USB controllers.... and Win11 has the TPM requirements etc.) while the Linux distros are debating dropping support for about 15 year old hardware and deciding not to do it.

Big problem

This used to be a big problem (and probably still is.) Ads that, instead of just offering the low pay so only H1Bs may WANT to apply, will openly apply *for* H1B workers. Or list false requirements like "10 year experience with SQL Server 2022"; if you don't list that when you apply, you haven't met their requirement; if you DO list that and you're not an H1B, they (accurately) accuse you of lying on your application and toss it in the bin. There used to be LOADS of jobs like that, they listed like "4-5 years experience with X, 7-8 years with y", those were ones were they had an employee already selected and listed their exact experience; after all, if you have 6 years of experience with x, that is not 4-5 years, disqualified.

The nasty part of it where I live is, jobs here can ALREADY pay much lower then they would if you lived in silicon valley or New York (similar to how, in Britain, the same job will have to pay much more in London than in the outskirts of the country); but these H1B farms would not adjust their prices properly to the local market, so they'd list "low" wages that were actually competitive in this area while still making it clear they were not going to actually let any locals apply.

The joke of it is the H1B program is specifically supposed to be for professionals that cannot be found locally; not to underpay and abuse people from overseas because there's tons of locals but they don't want to pay market rate. (An example of a legitimate use, when Siemens installs a nuclear reactor they use H1B visas to bring in some Germans for a year or two to train the locals in the care and feeding of the reactor.) I have no idea why the feds continue to allow the open abuse of this system. Luckily, people appreciate my excellent communications skills, attention to detail, and skill, and I've had no problems getting all the contract work I can handle.

Fine with me

Fine with me.

I think it may be a strategic mistake if they dump ARM entirely too quickly. There are those who just want to get the "one model faster" chip and not have to port anything.

On the other hand, Linux is portable, virtuallly everything that sits on top of it is portable (i.e. not x86/x86-64 or in this case ARM-specific), the kernel and compiler are ported to work with RISC-V. Even these embedded systems generally have a "linux from scratch" type of build setup, where they could probably just set the target from ARM to RISC-V, build, and have the full stack built, up, and running on RISC-V.

To be clear, this is in direct contrast to "Windows for ARM" where Microsoft has the NT-based kernel that was portable (x86, MIPS, PowerPC, PA-RISC, Alpha.. oh and at some point Itanium) like 20 years ago but with decades of code after that that was likely written with just x86/x86-64 in mind. I don't now if they've gone over things to make them truly portable, or if they've hacked in "ifdef ARM64"'s into the code. But just to say, porting Linux and a distro on top of it to a new architecture is far FAR easier that what I'm seeing from Microsoft (where, for instance, they're still working on getting visual studio up natively on ARM.)

OK, but...

OK, but...

1) OK, if other cloud providers are prohibiting it, then I guess go ahead. And I could see barring it due to the likelihood of non-payment.

but...

2) I also expect cloud plans to have (this was quite clear on the few AWS things I've looked at) "you get x units of CPU time, then get y amount of processing power after that" (essentially, they structure the plans so unless you're really paying enough to pay for using some CPU power 24x7 all month, you eventually get throttled down to a lower speed.) If it was a concern over capacity I would really hope Microsoft would just structure their plans like that, and then using a cheap plan for mining would simply be unattractive since you would not get the CPU power to do it 24x7, and plans with full CPU power 24x7 would be too costly to do it with.

Sensible

Sensible. Even without the current political situation, it's better to have geographically diverse fabs anyway. Shipping costs are only going up, supply chain delays (both of supplies a fab may need to operate, and of getting output shipped in a timely manner), more localized weather-related problems (flooding or snowstorm closing things down, or even having to shut down due to a heatwave), wide-scale natural disaster (earthquake, hurricane, or derecho*), power grid issues, or just having something random go wrong that shuts down some fab production. Also does make sense to keep the "state of the art" at some fab first, so they know what they're doing before they rolled it out.

*We had a derecho go through here in Iowa CIty, Iowa, derechos are nicknamed an inland hurricane. https://en.wikipedia.org/wiki/August_2020_Midwest_derecho . Had 80MPH winds where I lived for like an hour and a half from it and it did manage to peel some shingles off my roof; and about a 5 mile wide band of 120+MPH winds about 20 miles north of here (120MPH for about an hour with 140MPH gusts.) It's like tornado damage but instead of a damage path a few dozen feet up to maybe a mile wide, you have this huge dozens of miles wide damage path.There's a nice vid on there of an area about 50 miles wide and 200 miles long losing power.

Senisble

Sensible. 80 degrees F is not that hot, in days of yore they'd run the whole datacenter at like 68F, but it really is a waste of power, and I think part of the reason for that was you just generally had a big room with computers in it, no planned airflow or anything. The thing to watch out for would be hot spots, but I expect these facillities are designed to avoid having hot spots.

In case you wondered...

In case you wondered, "Why the qemu target?" It's for cross-compiling. It's possible to run a m68k cross compiler on your x86-64 boxx or whatever. But debian (for one) has a builld system where, to make sure the headers (.h files) are right, to be able to run the tests (to make sure a program built properly), etc., they favor running a build for some CPU type on that CPU type. For m68k, these build systems are almost always emulated (they have genuine 68k-powered hardware still, but building on like a 25mhz CPU is much slower than buildling on a qemu emulation that can probably emulate at 20x that speed.) So, why run on a qeu-emulated system with 1GB RAM emulating 1980s-era peripherals, when you can run on a qemu-emulated system with more RAM and the (in this case) Android-provided modern-style peripherals.

Even a stopped clock is right twice a day

Even a stopped clock is right twice a day.

Boris Johnson is an idiot, but I can't disagree with the public needing convincing on why blockchain exists.

Cryptocurrency? That does rely on blockchain, and is a legitimate use for it. I'm really addressing all the OTHER uses...

I mean, NFTs, each one goes through some single NFT site for that set of NFTs (several of these NFT sites have already closed up shop, so the blockchain just has a web address to a site that raked in millions of dollars then closed so your picture is not even there any more.) OK, the blockchain provides "proof" that you are the owner -- if you have any way to show you own a particular address on the blockchain. But since the updates to that ownership info are coming from a single site.... what's the advantage over having the site itself just keep track?

There's companies now planning to do like trucking/shipping logistics using blockchain. This solves a problem the companies don't have -- they aren't assuming bad actors trying to falsely claim ownership of a container (which blockchain would help with). They are concerned about not having interoperable systems, the amount of paperwork and moving info from one system to another involved. Which blockchain in no way helps with. So in this oft-cited case, blockchain solves a problem that doesn't exist.

There's various games and things that seem to use the word blockchain just to use it? They are throwing NFTs into the games so of course they'll use the term blockchain. Needless to say, this is just games that would have had in-game items purchased with in-game currency turning the "in-game items" into "Non fungiable tokens" to ride the hype train. And of course, games have had working systems to track sold items for decades before blockchain, so they may be using it but really don't have any reason to.

Bank transfers? A blockchain could fairly be used for this, perhaps. It's a matter of if SWIFT is tampered with frequently enough for it to even be worth the upgrade, and if blockchain would prevent it or not (one prevoius SWIFT attack I read about, a bad actor waited for money to be transferred from a bank to a temporary account, which would then transfer to the target bank moments later; they pulled the money out of the temporary account into a "legitimate" account in the SWIFT system. So, throw blockchain in, if they still use the temp account etc. it may not help one bit with tampering.)

Finally, there's a move to use blockchain for data storage, I guess? This sounds straight-up inefficient and I don't see the point of this.

In summary, shockingly I agree with Boris on something -- I do think blockchain is extremely hyped and not really fit for many use cases it's being shoved into now. The public indeed does need convincing if blockchain should be used for these things.

So all at once or piecemeal?

So does this have to be taken all at once, or could it be done piecemeal? Rather than taking off 3 months in a row (25% of the year), I'd be tempted to shift to 4 day work weeks (20% of the time taken off), leaving 5% (about 2.5 weeks) left over to take as unpaid vacation.

Of course, that depends on how good the pay is. If that 25% paycut for 25% less hours means you're not going to make ends meet, obviously it makes sense to go look for work elsewhere. And some may wish to do so anyway.

Repeater?

"NRK has reported on locations like Kråkenes in Kinn municipality where residents can only get signal in a very specific part of their homes due to the mountainous terrain, and yet landlines have already been shut off with no promise yet of a fiber connection forthcoming."

So why don't telenor stick a repeater or cellular amplifier up on the roof or whatever part of the house gets a signal, and let that cover the house? The problem to me is areas where they can go throughout the house and get no signal -- there's valleys in SW Wisconsin where the entire valley is convered, including of course the houses in those valleys. Compared to that, this to me seems like this has an easier solution for those households.

Have it both ways

I like how the Microsoft spokesman is like there's no problem with data protection, but they have "implemented many suggested changes to our data protection terms."

Anyway, good on the Germans. I'm a believer in privacy and I'm glad they are looking at how data is actually handled instead of listening to bland assurances that everything is fine.