Live data from Hacker News

Microsoft suggests command line fiddling to get Windows 10 update installed

theregister.com

161–170 of 223 posts

Re: Microsoft suggests command line fiddling to get Windows 10 update installed

#162

Earlier quoted context omitted.

Depends on distro and usage, but once installed Linux does not need command line fiddling. There are GUIs for installing and updating the OS and applications and pretty much everything else an average user does.

In that case I will have to disagree. I run a stock, up to date Ubuntu. Yes, there is a GUI for a lot of things, but I will most certainly run into something that will require me to drop to the CLI before long – which I am fine with, but I am not going to pretend it won't inevitably happen. My experience is: On Windows, for most enduser use cases (and this absolutely excludes anything dev related), I would expect the…

I disagree. On stock Ubuntu, there is no normal situation you'll run into where you must use a terminal. If you decide to do something that requires a terminal, that's a different story. But basically every normal operation you'd do on windows GUI (and more...), you have a GUI option available on Ubuntu; it is the Windows of the Linux world, and it behaves as such.

Re: Microsoft suggests command line fiddling to get Windows 10 update installed

#163
post #147
post #17

Haha! Yes, this was a mess! I was called to help my concerned stepson with "an update error" this past weekend. I'm a software engineer but even I kind of balked at it at first, realizing how very easily an on-the-fly resizing of partitions can go wrong! Let's take it from the beginning. He pointed me to the "out of disk space" error code, which isn't in text form to begin with, but only something you find out by goo…

You've skippedd to the tough spot, but before that - actually, why is 300mb not enough?

Windows install ISO is 4.7GB. 300MB-500MB seems in line with what core restore files would require.

Re: Microsoft suggests command line fiddling to get Windows 10 update installed

#164
post #54

Earlier quoted context omitted.

This is why I am extra vigilant, pendantic and strict when writing or reviewing code that handles exception and error paths. More than happy-path code, I want this to be simple, rediculously easy and very loosely coupled. No inheritance, no abstractions, very shallow dependency trees and so on. Just once too often did a bug in exception handling cause a system to go down - It is often not or hardly covered in tests (…

This attitude seems a little silly to me—being "extra vigilant, pedantic and strict" about happy-path code would necessarily imply the same about "exception and error paths". Generally speaking, bugs mostly appear in a binary fashion and not in varying degrees—ie your code either reflect expected behavior or doesn't.

As a game developer, I definitely distinguish high-risk and low-risk parts of the code base.

There's code that can be allowed to fail, and furthermore, it will eventually fail due to the sheer amount of this code, the development time constraints, the number of possible game states, etc. I don't care that this code rarely fails under some arcane conditions, because this simply causes some button to stop working, some NPC to stop moving, but the game will remain playable. Even if the player notices the bug, they'll just shrug and keep playing. My aim is to make sure that the game recovers and returns to a healthy state after the level/save is reloaded. (Obviously, I'd like to fix/avoid every single possible bug, but it's impossible in practice. You'll have more luck continuously tracking in your head how dangerous the code you're working on is. Also, you rarely have the luxury of being the only programmer on the team. Bugs will happen.)

The other kind of code is the core game system stuff, the low level stuff, the error handling stuff, the memory stuff, the pointer stuff. You must pay special attention while working on this code, because failures will straight up crash the process or bring the game into an irrecoverably broken state (eg. all objects stop updating, stuck in some menu, the player never respawns...). Bugs like these are also highly prioritized by management. My update loop needs to be shiny.

Such is the reality of working on complex systems (or simple object-oriented programs ;))

Re: Microsoft suggests command line fiddling to get Windows 10 update installed

#165
post #54
post #7

When installing the update, some users are finding themselves faced with an 0x80070643 error, a generic failure message. Unfortunately, according to Microsoft, "because of an error in the error code handling routine," this might not be the correct error. Error in the error code code is giving the wrong error code for the error. I'm curious how often the error code code needs touching that there is an error in there t…

This is why I am extra vigilant, pendantic and strict when writing or reviewing code that handles exception and error paths. More than happy-path code, I want this to be simple, rediculously easy and very loosely coupled. No inheritance, no abstractions, very shallow dependency trees and so on. Just once too often did a bug in exception handling cause a system to go down - It is often not or hardly covered in tests (…

Exceptions are by definition where some “unknown unknowns” are going to show up, so yes, it’s good to have simple code with as few assumptions as possible. At the extreme, you get Erlang-style supervision or “crash-first programming” where at the first sign of trouble you just immediately throw away all ephemeral state and start over.

Re: Microsoft suggests command line fiddling to get Windows 10 update installed

#166

Earlier quoted context omitted.

I mean, how often is quality software made? I agree with you, but I'd argue most software is compromised by shitty incentives. Humans mostly write buggy and incoherent software—this is solved by consensus across disparate incentives. The "primary goal" as you state is often characterized by others as "bias"

> I mean, how often is quality software made? I have no idea what you mean by quality software, so I can't answer that. Can you give an example? I also have no idea what your alternative framing is. It seems like fundamentally not how people think of software. > The "primary goal" as you state is often characterized by others as "bias" ...yes, that's the point of I (and I believe the others) have been making. People…

> Were you actually saying that you really did believe everyone else was worse at programming?

What? I'm surely just as vulnerable to giving a shit about the happy path as everyone else. I'm just saying this leads to bad software, and anywhere you see good software produced you see people giving inspection to the code paths they suspected were error-free. The conception that giving extra attention to the error path leads to better software seems to entirely confuse the concept of a flawed program with some kind of finite bulk work that needs to be done.

Re: Microsoft suggests command line fiddling to get Windows 10 update installed

#167

Earlier quoted context omitted.

Two monitors with different DPI. Couldn't get them to work well without running a weird xrandr script on every boot with some "1.9999999999...." setting.

Without Wayland I'm pretty sure this is still the case.

I use Wayland. Perhaps that's your issue?

Re: Microsoft suggests command line fiddling to get Windows 10 update installed

#168
post #54
post #7

When installing the update, some users are finding themselves faced with an 0x80070643 error, a generic failure message. Unfortunately, according to Microsoft, "because of an error in the error code handling routine," this might not be the correct error. Error in the error code code is giving the wrong error code for the error. I'm curious how often the error code code needs touching that there is an error in there t…

This is why I am extra vigilant, pendantic and strict when writing or reviewing code that handles exception and error paths. More than happy-path code, I want this to be simple, rediculously easy and very loosely coupled. No inheritance, no abstractions, very shallow dependency trees and so on. Just once too often did a bug in exception handling cause a system to go down - It is often not or hardly covered in tests (…

Same. I shut down a ticket last week that would create an “final” error handling path that happened to re-invoke half the code paths that could error.

Re: Microsoft suggests command line fiddling to get Windows 10 update installed

#169

I also got this error... if I understand this correctly, they want a recovery partition of 250 MB... but I already have a recovery partition of 500 MB (acc to disk management, and lists it as 100% free)... so why am i getting this error? should I increase it by a further 250 MB (for a total of 750 MB), or are they just plain crazy?

The update requires 250 MB of _free_ recovery partition space, not the total size of the partition.

but my 500 MB partition is listed as 100% free by disk management

is it that not accurate? how do i find out how much actually free space i have?

Re: Microsoft suggests command line fiddling to get Windows 10 update installed

#170
post #165
post #54

Earlier quoted context omitted.

This is why I am extra vigilant, pendantic and strict when writing or reviewing code that handles exception and error paths. More than happy-path code, I want this to be simple, rediculously easy and very loosely coupled. No inheritance, no abstractions, very shallow dependency trees and so on. Just once too often did a bug in exception handling cause a system to go down - It is often not or hardly covered in tests (…

Exceptions are by definition where some “unknown unknowns” are going to show up, so yes, it’s good to have simple code with as few assumptions as possible. At the extreme, you get Erlang-style supervision or “crash-first programming” where at the first sign of trouble you just immediately throw away all ephemeral state and start over.

A good reliable system pretty much has error handling every step of the way, down to crash-first programming at the very end.

It’s more possible to recover from errors higher in the system but you can’t predict every problem so you need layers of error handling at increasingly lower levels with different recovery expectations.

Post reply on HN