“How is babby formed?"
[EDIT] Corrected quote
I actually missed the original.
Sysadmin story. Recently I had a really strange problem after a disk migration - defrag.exe simply would not run no matter what (I needed it to TRIM the SSD), it just quits without any messages, as if it's /bin/false. GUI had the same problem.
The first search result was a thread at answers.microsoft.com, they give the same canned "sfc /scannow, dism /restorehealth, chkdsk /f" response. But OP finally solved the problem on their own, the "Optimize Drives" service was somehow been stopped, restarting it solved the problem. I tried it, it didn't work. Having no options, I decided to give the seemingly useless solution a shot (why did I bother to try? This was after a disk migration, I felt filesystem corruption could be real). It finally worked after "chkdsk /f"...
I was genuinely impressed. It was the first time ever that it actually fixed a real problem for me. Presumably defrag.exe detected a filesystem anomaly and refused to run.
Would be interested in the logic here, given that it runs counter to what I thought was extremely obvious advice by now.
Defrag generates writes to rearrange blocks in the _virtual_ view of storage visible to the OS, but even after defragmentation, the _physical_ placement is totally outside the control of anything except the firmware. If after defragmentation a file's blocks are arranged (0, 1, 2, 3) in the OS-visible view, in flash are still very likely to to be arranged (412, 77, 1, 12341, 5) etc. All you can do is let it know that some range of sectors is not used, which is what TRIM enables, and that does not require defragmentation upfront.
This is exactly what defrag.exe does on an SSD today. Since Windows 10 (or 8?), instead of doing a "real" defrag, defrag.exe also has an option to issue TRIM commands to unused blocks on an SSD. In other words, it works like fstrim(1). The time has changed and you must have missed the update. I suggest keeping your knowledge up-to-date before delivering a lecture on disk defragmentation on a forum where everyone should've known better.
https://docs.microsoft.com/en-us/windows-server/administrati...
> /d Perform traditional defrag (this is the default).
> /l Perform retrim on the specified volumes.
> /o Perform the proper optimization for each media type.
Since I migrated the hard disk using a block-level copy via "dd", it's a good idea to manually TRIM the disk afterwards to inform the controller about the unused blocks in the new filesystem for proper wear leveling (to the controller, the block-level copy looks like a single large file).
And before another one gives me another lecture: No, I did not corrupt the filesystem because I made the mistake of copying the disk while Windows was still in Fast Startup mode. It was probably ntfsresize(8), to be fair, the corruption was extremely minor.
I had to go to like page 10 of Google results to find some random sysadmin's blog which looked like it came straight out of 2005 and guess what? Problem is explained clearly, steps to fix it are laid out, sorted and wish I found the website 2 days earlier.
- It is was often unclear what version of the “thing” was in scope. An article from product version X will reference X-1 documention.
- Microsoft will gaslight you. If you interact with them on a significant issue, you need to snapshot their product docs. I’ve worked with Premier on issues when pushing products to the edge of their limits, and the product group will edit the product specs in near real-time.
That issue left a sour taste in my mouth. As a customer, I don’t really need to be in the middle of corporate politics, I have my own poisonous politics to deal with!
I share it because many folks can’t conceive that sort of thing being possible.
This was during .net 4.5 fyi, ages ago by now.
Powershell, though. I don't know how you could even document powershell. It's insane.
Does anyone know if there’s any sort of reflective documentation or anything in powershell? Like, is there a way to ask it what arguments exist for a command?
Also just FYI, it can fuzzy match on arguments, so you can specify only the first letter, or substring of the whole name. I think from this aspect, it is far superior to the UNIX tools.
Sometimes I write the same script as PS and as bash script. For PS I usually need 3x more characters than for bash.
There are some features though that are really useful. But most of the time you won’t know about them when you need them.
That's your mistake! Don't write bash scripts in PowerShell, and don't write PowerShell scripts in bash. Don't be surprised if the shopkeeper can't understand you, when you're speaking "French" by translating an English sentence word for word.
PowerShell is much more readable, terse, and elegant than Bash. It absolutely blows it out of the water... on Windows, where its inputs are the streams of objects that it's designed for. If you're trying to shoehorn text-based streams like in Linux into a PowerShell script, you're going to have a bad time.
See this earlier comment I made and the linked comments for some examples of PowerShell-vs-Bash: https://news.ycombinator.com/item?id=23423650
A sterling example of PowerShell's inanity is its brain-dead, ivory tower implementation of function return values. Anything that outputs to stdout gets added to the return value object for your function. Forgetting for a moment how non-standard and unexpected this is, consider that it’s impossible to completely silence many, many Windows commands CLI programs and utilities. Even with all the silent flags, output redirection, etc. it is simply impossible to silence stdout. What you end up with is... you just can't ever use return values in functions since it's so unreliable. This, coupled with PowerShell's atrocious performance (it's the worst performing scripting language I've used by far) instantly makes PowerShell a second class language for anything apart from very small scripts.
I've never heard anyone call PowerShell “terse” until today. It is currently winning the competition with Java for “Language whose inventor is most likely paid per keystroke”. PowerShell's arguments are extremely verbose and lines tend to become quite long as a result.
Disclaimer: I’m a recovering Windows Admin and haven't used PowerShell in a few years. I'm told that none of these problems have been fixed, but I don't know for a fact.
This is most obviously noticeable (to me at least), when debating ergonomics with people that prefer UNIX platforms, especially bash and text-based configurations. There was a study that showed that an action like moving a mouse to select a file feels slow because there's one slow movement, but selecting the file through typing at a console is perceived to be faster because there are many keystrokes in quick succession. People report that they prefer the latter for "the speed" even if it's an order of magnitude slower than the mouse if measured with a stopwatch.
The terse two-character commands of the UNIX world were an optimisation for teletype. As in a literal typewriter banging away on paper, at a rate of something like 10-30 cps. Modern (four-decade-old!) computers have tab complete, which makes this largely irrelevant.
Verbose commands are an enabler. They enable novice users to read scripts, instead of only masters being able to write them. Long, systematically and consistently named commands enable discovery through wildcard searches.
You cannot now -- nor ever will be able to -- do something like this in the Bash world:
Get-Command Get-Az*Disk*
That's not an option because Bash doesn't actually follow the UNIX philosophy: it's not composable, it's not orthogonal, it's not designed, it's not self-consistent, etc...It's a clever hack around byte streams that people have slowly built up over decades, evolving over time haphazardly. There was an 'sh' for example!
PS: You talk about using Python instead of scripting languages, which is actually a fine choice that I won't argue with. But have you considered writing "heavyweight" PowerShell modules in C#? As in, a proper DLL module? It's mindblowing how productive it is compared to trying to write a command line tool in C/C++, or any other language for that matter. Automatic input validation, input parameter name tab-complete, pipeline handling, all wired up with a handful of attributes...
For short scripts, this works great and improves discoverability for newcomers. This is the siren's song of PowerShell. However, the long commands and particularly the often unneeded/overly verbose parameters frequently creates a wall of text. This really hurts readability for everyone in all but the shortest scripts. Additionally, this wall-of-text that is all to common in PowerShell scripts is very intimidating to newcomers.
Regarding Tab completion in PowerShell, it frequently isn't terribly helpful. To work yourself up to something like Get-ItemPropertyValue is quite an incantation to remember, while being worse than a lot of bash ergonomics.
> have you considered writing "heavyweight" PowerShell modules in C#?
That is an interesting approach and would make life more bearable in MS-only shops. However, I can do the same thing with Python, which is superior to PS in so many ways and doesn't suffer any huge, glaring flaws (as PS does).
Filter is harder than it should be[0]. Same thing for map
[0]: https://www.concurrency.com/blog/august-2018/powershell-basi...
It's like they hire an army of noob-level interns who churn out "getting started" articles, with the end result being that you have to dig 5 pages deep into Google result to get meaningful documentation (4 of those pages are of people asking questions on Microsoft Connect or the-site-that-shall-not-be-named or something).
Azure and Powershell docs leave a lot to be desired. A lot of the time parameters are vaguely documented, return values completely undocumented. You have to inspect the object returned by a lot of things to get to understand what members and methods it has, and what they mean.
Examples illustrating what formats it expects inputs in? Forget it.
In contrast, Win32 which has been around for over 25 years is mostly stable now.
More than once, the "solution" to my problem was a blog post by a SharePoint consultant from India describing some undocumented flag to pass to some obscure command, "but of course, you should never do this on a production system". (I bear no ill will towards Indian SharePoint consultants, to be clear. I just find it really creepy they seem to enjoy this kind of torment.)
Just get-help -full/get-member everything or export-clixml it. But maybe I've done it for too long, so I don't see the weaknesses anymore.
An example of a place where it's bad is the Python API for Azure. I needed to call some service, I forget which, and everything was clearly just translated from C#. There's a function which takes a string as an input, except it doesn't, it takes one of three string, neither of which is mentioned. I assume that in C# it's an enum, and Visual Studio will just list the option for you.
“if you know how to read it” is...not a ringing endorsement of documentation. But, its true that MS documentation is less likely to be wrong once you understand what it is trying to say than, say, Amazon's (though have glaring omissions or things concealed by opaque organization is quite common.)
While I'm sure the complaints are valid (or was in the MSDN days) I believe Microsoft is putting a lot of effort behind these pages. You can provide feedback on pages that will result in a GitHub issue being created. You can even make pull requests.
While it's possible to provide feedback not all areas seem to process this feedback in a timely manner which of course is frustrating. However, the good parts (like .NET) are very good.
I think my issue might be more with the English style. But why does SO work right-away for me, while other these other developer portals don't. Part of the flaw maybe lies with me - maybe these portals (like MSDN) need in-depth, patient reading (guilty here). SO on the other hand, is way quicker in helping to solve issues. Over the years though, I've had enough bad experiences ..
Someone should do a compare between SO and non-SO. Take a sample, discrete (if such a thing exists in software issues) issue, and see how both help to solve. The layout of the page, the noise, and finally the curated/voted answer all contribute. And factor in the fact that SO answers are written by a diverse group of people, many of them non-English speaking.
Call it hate, but regardless, Oracle product docs - when you're in a bind are the bottom of the pit.
Stack Overflow excels at showing implementation examples which, while the best way is not always highly rated, at least shows a way. When I was more junior I would sometimes take SO answers verbatim but I think now it at least gives me something to think about improving.
Because a list of errors that could occur and a comprehensive list of what is recoverable (and how) vs what should abort is not useful at all in developer documentation…
Just most links seem to be broken.