[HN Gopher] Jeffrey Snower was originally demoted over PowerShell
___________________________________________________________________
Jeffrey Snower was originally demoted over PowerShell
Author : nocture
Score : 170 points
Date : 2022-05-08 08:06 UTC (14 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| joshbaptiste wrote:
| Today's tech worker would have quit and launched a startup and
| have Powershell become the Enterprise "Ansible" add-on of Windows
| to then subsequently be acquired by Microsoft for [m|b]illions..
| ZhangSWEFAANG wrote:
| I like the regex touch
| vessenes wrote:
| This is an intriguing peek into some upper echelon MS politics.
| He notes he got busted down from L69 to L68 - L68 is a
| significant cutoff inside MS, titled "Partner". L70 is
| "Distinguished Engineer". For recent years, L68 all-in comp is
| probably right around $1mm a year, although I'm sure that was a
| bit lower when PowerShell was being written, and much higher in
| toto if you held on to your RSUs.
|
| What surprises me is everything _not_ said here - I know a number
| of MS Partner-level folks, and they all strike me as perfectly
| capable of funding and hiding a reasonable-sized team to work on
| anything they think is important; in fact reducing and removing
| precisely this practice is one of the reforms Satya has made --
| getting upper echelon fiefdoms more aligned.
|
| So, I think the full story is actually a lot _more_ interesting
| than the tweets. I'd personally like a short memoir instead of
| the tweets. In any event, don't feel too bad for him - he did
| fine, and PowerShell is one of the features that let Windows stay
| competitive with Linux as the world transitioned to the cloud.
| hintymad wrote:
| > For recent years, L68 all-in comp is probably right around
| $1mm a year,
|
| This is in stark contrast of how people below 67 got paid.
| Their packages have been visibly smaller than those of similar
| roles in FANNG-like companies. I think this is because
| resources will concentrate to the top as a company becomes
| bigger and older most likely because visibility disappears
| quickly among lower ranks and what they do individually hardly
| matters. If the theory is correct, the natural conclusion is
| that one should really seek a career in a fast-growing company
| unless they are great at navigating a big co's dynamics.
| janandonly wrote:
| And rightfully so...
| georgia_peach wrote:
| In the cosmic sense, the demotion was lenient, considering that
| he breathed new life into something which is mostly an
| abomination, & should have been put out of our collective misery
| long ago. The cybersecurity industry would be a shadow of its
| current self if it weren't for good old Windows.
|
| The ACM needs an "H.P. Lovecraft Award" for such situations.
|
| _Jeffrey Snower: RE-ANIMATOR_
| pipeline_peak wrote:
| If I had to guess why, maybe because PowerShell is a little
| "busy". It always feels unclear whether he was trying to make
| something similar to Unix Shell or a shell for the .NET
| environment. It's greyed somewhere in between in a confusing and
| inconvenient way. Something as simple as a diff requires using
| objects, it just doesn't feel like it was designed with SysAds in
| mind.
|
| My guess was it had to do with marketing, sort of like how JS
| started off as a Scheme dialect, but higher ups enforced Java
| Syntax. .NET was pretty new at the time.
| luma wrote:
| As a sysadmin, you can pull pwsh from my cold dead hands.
| Evrything being an object is a feature, not a bug. Going back
| to bash feels like going back a half century.
| cm2187 wrote:
| It has its rough eges though. The one that pisses me off is
| psremote. Complex to set up, takes forever to come online
| after a reboot, runs in a network context which isn't allowed
| to interact with certain windows APIs, not the least windows
| update. How you create a remote shell that cannot do
| something as simple as updating the OS is beyond my
| comprehension.
| andrew_ wrote:
| I'd like to know why Snower accepted abuse from corporate
| overlords for 5+ years (according to the thread). Being "in the
| dog house" for that long is ridiculous on the surface. That would
| never stand in today's world of tech. Is he just oldschool and
| had the mindset of "the company is always right"? Is he just a
| company man with intense loyalty? I would understand the company
| not adopting it and having to spend five years advocating for new
| tech in a company that large. But I can't understand why being
| demoted and punished for 5 years. I grew up with a major emphasis
| on work ethic but I can't wrap my mind around this.
| birdyrooster wrote:
| They make a joke of it in Silicon Valley, "Rest and Vest" check
| out this clip: https://www.youtube.com/watch?v=y30pML-AW4k
| rtpg wrote:
| Probably he was still getting paid a lot? It is MSFT after all.
|
| I imagine that a certain kind of person, willing to write
| tooling and even get demoted for it, is willing to stick around
| with a bit of a pay cut anyways.
| tptacek wrote:
| The Microsoft of that time period was infamous for
| deliberately paying less than other tech giants.
| Wistar wrote:
| Absolutely true.
| tptacek wrote:
| They had an actual formula for it, and I'm forgetting
| what the number was. Like 80% of some metric of other
| tech giant comp?
| ThrowawayB7 wrote:
| 66th percentile of the industry for equivalent positions
| is what was reported.
|
| Anybody who could get more than the 66th percentile
| elsewhere, more power to them. Anybody who thought that
| "66th percentile" meant they were being paid less than
| average, well, their departure was probably regarded as
| good attrition with a chuckle.
| gpvos wrote:
| What other interesting jobs are available in the region, how
| willing are you and your family to move, etc., so many
| factors.
| opencl wrote:
| The region is Seattle, I don't think there was a lack of
| other options if he really wanted to leave.
| birdyrooster wrote:
| Live in California long enough and your work ethic will melt
| and your life will become much more interesting.
| andrew_ wrote:
| hypertele-Xii wrote:
| HN guidelines:
|
| > Please don't comment about the voting on comments. It never
| does any good, and it makes boring reading.
|
| https://news.ycombinator.com/newsguidelines.html
| andrew_ wrote:
| Sigh. it's not a comment _on_ the downvote, it 's a call to
| those down voting to participate to enhance the convo. If
| you read the rest of the guidelines, they also state not to
| cite the guidelines as a reply.
| gumby wrote:
| I would not have downvoted your comment but IMHO saying
| "don't be a coward" is the wrong tone to take here.
| striking wrote:
| Which guideline states that?
| bigbillheck wrote:
| Downvotes and upvotes are just imaginary internet points
| and you should not become attached to them.
| gumby wrote:
| That's only true until someone puts them on the
| blockchain.
| Sakos wrote:
| You know what makes for boring reading? People not engaging
| in discussion at all and just relying on downvotes to
| convey their opinion.
| throwaway787544 wrote:
| It's because he was interested in philosophy (particularly
| Leibniz). He also left a job he liked just to develop
| PowerShell at MS. (he wrote an entire manifesto about it)
| pyb wrote:
| What makes you think he didn't try to change jobs? It's not
| like tech interviews are designed to detect this kind of
| talent.
| agent86 wrote:
| Question for the more seasoned Mac/Linux folks on HN:
|
| Powershell has been a gift in getting things accomplished in
| Windows. But one thing I've also come to enjoy using it for is
| quick and dirty interactions and scripting with REST APIs.
|
| Things like Invoke-WebRequest, ConvertTo-Json/ConvertFrom-Json,
| Export-CSV, piping between almost everything, and the results
| being passed around like an object that I can use SQL-ish Select
| queries against, etc.
|
| I find myself feeling like I'm missing something helpful when I'm
| on a Mac/Linux device. Is there a similar go to in the Mac/Linux
| world for this type of stuff? My current thinking is that I
| either have to start picking up Python or building a mental map
| of wget/awk/grep type commands that can be chained together for a
| similar effect, but I thought it best to try to learn from the
| wisdom of others first :-)
| closeparen wrote:
| This is the fundamental differentiation of Powershell, right?
| UNIX operates on text streams while Powershell operates on
| structured data. It is in a better position to do this kind of
| stuff.
|
| That aside, a lot of contemporary cloudy CLIs will now speak
| json on stdin/out and JQ will make any json transformations you
| can imagine.
| digisign wrote:
| Yes, you can use Python just about anywhere, and it is arguably
| more sane/readable. Prefer httpie over curl at the command-line
| as well.
| paramost wrote:
| Not a seasoned mac/Linux user, but would powershell core not
| work? I believe it's cross platform?
| jhugo wrote:
| curl, jq
| pouting wrote:
| Powershell 7 is cross-platform.
| magospietato wrote:
| Is there a similar go to in the Mac/Linux worlds? Yeah, it's
| called Powershell 7! Powershell was ported to cross platform
| dotnet a few years back. Currently running some Powershell
| scripts in production on a Linux box.
| rektide wrote:
| "You can use powershell" isnt quite the same as asking what
| the open source world does. Adoption of powershell on
| Linux/Mac is tiny. If you show up on a random system, it
| almost certainly will not be available.
|
| It's good to know powershell is cross platform now. Good to
| know this can be an option. But I'd also say the original
| question still deserves more exploration & thought, that
| asking what the romans do in rome is good to know too.
| rektide wrote:
| Curl, jq is the good answer here.
|
| More from the fringe, I'm quite enjoying zx, a really nodejs
| powered scripting environment. https://github.com/google/zx
|
| Covered somewhat in ZX 3.0
| https://news.ycombinator.com/item?id=28195580 (189 points, 8
| months ago, 163 points)
| jiggawatts wrote:
| These are only vaguely comparable. It's like saying assembly
| language is a substitute for something elegant in Haskell.
|
| Technically true in some sense, but not really.
| sjellis wrote:
| There are a few projects that take inspiration from PowerShell,
| but they haven't got mass adoption. I have hopes that Nushell
| will be a success when it gets to 1.0:
|
| https://www.nushell.sh/
| dredmorbius wrote:
| https://threadreaderapp.com/thread/1523010444570419200.html
| outside1234 wrote:
| I have worked at Microsoft off and on for more than 20 years and
| it is insane how many disaster stories boil down to super
| horrible Windows management.
|
| ".NET cross platform?" -> Windows screwed it up
|
| "Phones" -> Windows screwed it up
|
| "Azure Linux VM" -> Windows screwed it up (but thankful we fired
| them and fixed it)
|
| One of best things Satya has done is essentially fire almost all
| of these morons.
| csours wrote:
| "Remember the human". Do you start with the assumption that the
| product has to fit into Windows and do things the Windows way?
| Or do you start with the assumption that humans are going to
| use the product and make it in such a way that people can and
| want to use it.
| nobodyandproud wrote:
| In the late 2000s or early 2010s is when I first read about
| PowerShell (v1? it was still bleeding edge) and my jaws dropped.
|
| Ability to work with both .NET and COM objects? Piping objects
| and not strings?
|
| Absolutely amazing and useful tech, and I had to reread to make
| sure I wasn't reading about some future plan.
|
| I wonder which division pushed hard to demote; the Windows
| division?
| [deleted]
| einpoklum wrote:
| Question for the PowerShell afficionados: Do you consider
| PowerShell to be "something we can count on to exist on Windows
| systems, in the absence of Bourne-like shells" - or is it "a
| superior alternative to Bourne shells which only got traction on
| Windows because Bourne is too deeply embedded in the Unix world"?
| oaiey wrote:
| Bash as a shell is not so outstanding. It is the gnu tools and
| the other command line first Landscape. So bash on windows can
| never fly because these tools are not natively present (cygwin
| and friends are just awkward).
|
| So Powershell (and the new terminal) gives us this whole
| package with its build-in, service and windows provided
| commandlets.
|
| Consequently: bash will never beat PS on Windows except when
| someone provided a gnu tools and hundreds of other command line
| tools for windows.
| smackeyacky wrote:
| WSL2 availability makes powershell redundant for most server
| oriented dev tasks.
| justsomehnguy wrote:
| Translation: WSL2 makes running traditional tools for
| managing *nix servers easier from a Windows machine.
| oaiey wrote:
| Dev tasks. Yes. Admin tasks: not so much. The ask is not to
| create a windows client env to administer Linux machine.
| The ask is one management surface for Linux and Windows
| servers.
| oaiey wrote:
| On the topic of Powershell on Linux I think the story there
| could be different, however Powershell violates the core
| philosophy of Linux so hard (mit vs. GPL, pipe-and-filter vs
| loaded DLLs, ...) that Powershell will never be something
| integral and natural fitting there.
| sidpatil wrote:
| > mit vs. GPL
|
| By this measure, we shouldn't be using X or Wayland because
| they're MIT.
|
| > pipe-and-filter vs loaded DLLs
|
| At first I didn't understand what you were referring to,
| but I realized you were talking about cmdlets. In that
| regard, PowerShell is more like a scripting language than
| it is like a traditional Unix shell.
|
| The more "Unix-like" approach would be to write thin
| command-line wrappers around the libraries you want to use.
| If I'm not mistaken, this is how projects like LAME and
| FFmpeg are implemented.
| oaiey wrote:
| Regards the licencing: you are right. I was a vit blinded
| by the core gnu tools.
|
| Tiny wrappers do not work since .NET, while being very
| Performanz will never be C like tiny.
| sidpatil wrote:
| > Tiny wrappers do not work since .NET, while being very
| Performanz will never be C like tiny.
|
| I meant tiny wrappers around non-.NET libraries, to
| approximate the functionality you get in PowerShell in a
| traditional UNIX shell.
| [deleted]
| AndrewDucker wrote:
| Dealing with objects rather than strings and parameter
| autocompletion give massively better discoverability than other
| shells I've used.
|
| Being able to use all of the .Net classes trivially is also
| staggeringly useful.
| lazypenguin wrote:
| Honestly I enjoy writing powershell more than bash scripts.
| Bash syntax is arcane and sometimes inconsistent where as
| powershell 7+ is fairly comfortable syntax.
|
| However, powershell does often feel cludgy and I often have
| have to figure out how to do more complex things. Not a perfect
| solution but it integrates with Windows nicely.
| jrsj wrote:
| (Not an aficionado) I feel like it _is_ superior in many ways,
| but the syntax and case sensitivity have always been a barrier
| for me. It's still worth it though when it's the right tool. I
| don't do Windows stuff often though so it's always jarring
| coming back to it from bash.
| juki wrote:
| > syntax and case sensitivity have always been a barrier for
| me
|
| Can you clarify that a little? PowerShell isn't case
| sensitive, and the syntax is just a mixture of traditional
| shell syntax (pipes, operators like -eq/-ne/-lt/-gt, etc.)
| and conventional C#-like syntax (if/elseif/else, switch, ?:,
| ??, try/catch/finally/throw, etc.).
| jrsj wrote:
| There's some gotchas with case sensitivity that I honestly
| can't remember but I think it was related to some of the
| more C#-y bits.
|
| As for syntax it really is the .NET elements & the relative
| verbosity of common things you'd interact with that just
| make it feel very foreign to me personally. This probably
| has more to do with Windows and .NET than PowerShell itself
| though.
| drblast wrote:
| It's a better design, imo.
|
| Have you ever wanted to write a command line executable and
| gotten hung up on I/o and parameter parsing?
|
| With PowerShell you can write a cmdlet in C# as a PowerShell
| module and have strongly typed input and output parameters for
| free. It's a revelation.
|
| As as scripting language, it's fine but for me the killer
| feature is being able to easily extend it in a non-scripting
| language.
| jodrellblank wrote:
| > " _Do you consider PowerShell to be "something we can count
| on to exist on Windows systems_"
|
| Once, yes; then they renamed it "Windows PowerShell" and
| deprecated it so it's no longer being developed. Instead they
| started trying to appeal to Linux users with new cross-platform
| "PowerShell" which you have to install separately. Windows
| PowerShell is increasingly falling behind that in performance
| and compatibility. We're heading away from "PowerShell
| included" back to the old world of "if you have to download and
| install something to get away from this abandonware legacy
| thing, why not Python or node.js?".
|
| > " _a superior alternative to Bourne shells which only got
| traction on Windows because Bourne is too deeply embedded in
| the Unix world "?_"
|
| It's a superior alternative to Bourne shells _on Windows_ , and
| because it's basically Microsoft-Perl or Microsoft-Clunky-
| Python as well as being a shell, as in - it's more capable than
| Unix shell because it's a kitchen sink of scripting and
| programming language as well as command line.
| rufius wrote:
| The latter. I say that as someone who only works with _nix
| systems for the last 5 years. I still write some powershell for
| stuff at home. I prefer Hyper-V as a hypervisor and use it
| there.
|
| But the current state makes sense. Everything in Windows is
| COM, .NET, or a derivative thereof. Having a scripting language
| that natively speaks to these technologies in a flexible manner
| is a natural extension.
|
| _nix is a lot more of the file based stuff and so a shell
| language that makes it easy to run a series of tools that
| operate on text is natural (I.e. awk, sed, grep, xargs)
| Arnavion wrote:
| ... Neither?
|
| It's a superior alternative to cmd.exe. bash has never been a
| serious contender for Windows. Before PS you always wrote .bat
| scripts for cmd.exe (or .vbs for cscript.exe if you were really
| depraved). Nobody except Linux-first FOSS authors would expect
| Windows users to have cygwin / msys / mingw32 installed.
|
| PS gave us a saner choice, though we would still usually bundle
| it with a .bat wrapper, just to a) make it double-clickable and
| b) set `-ExecutionPolicy Unrestricted`.
|
| If you're asking "is PS better than bash", then sure it's
| better in some ways and worse in others, but that question only
| makes sense on Linux where bash is actually an option.
| einpoklum wrote:
| But instead of coming up with PS, it would have been pretty
| straightforward to just install bash on Windows. Someone
| chose to go the PS way rather than the bash way. My question
| is what the reason was for making this choice.
|
| > Nobody except Linux-first FOSS authors
|
| Bourne shell and its predecessors and successors are
| traditional and common on most computer systems since the
| early 1970s (starting with the Thompson shell in 1971; see:
| https://en.wikipedia.org/wiki/Unix_shell )
|
| so, I would argue actually the other way around. "Everybody
| except Windows-only closed-source authors would expect people
| to have bash or similar shell working." The question is, why
| go for PS instead of adopting a regular shell.
| Arnavion wrote:
| I'm really not sure what your point is.
|
| >Someone chose to go the PS way rather than the bash way.
|
| Are you asking about users or the Microsoft employees who
| work on Windows? Users don't want to install either bash or
| PS, which is why before PS existed all scripts were written
| for cmd.exe which was guaranteed to be available. Microsoft
| employees would have no benefit from adding bash to Windows
| given its license, and PS integrates better with the OS
| anyway. The author of PS is already on record that one of
| the original reasons was to integrate better with WMI etc
| [1]; given how hard / impossible it is to munge the output
| of ls etc in bash it should be no surprise than an object-
| based shell with saner expansion rules works better.
|
| >> Nobody except Linux-first FOSS authors
|
| >Bourne shell and its predecessors and successors are [...]
|
| You don't have to give me a history lesson. What you said
| has nothing to do with the fact that the only people who
| expected Windows users to have bash were Linux software
| authors, because their software only supported being built
| by bash scripts (and required make, configure, perl, what
| have you). Windows software itself, whether open or closed
| source, was built using cmd.exe scripts or VS project
| files.
|
| [1]: https://stackoverflow.com/a/573861/545475
| jodrellblank wrote:
| J. Snover started out bringing Unix (VMS) shell to Windows,
| and it isn't a good fit. Everything isn't text and so the
| Unix shell tools are pretty limited. So they made something
| which is a good fit for Windows everything-is-an-API
| instead.
|
| > " _The question is, why go for PS instead of adopting a
| regular shell._ "
|
| The question is, why stick with 1970s stuff when you can
| have progress?
| raverbashing wrote:
| Let's be real honest here, bash sucks.
|
| "common on most computer systems since the early 1970s"
| yes, that's exactly the problem, it still thinks spaces on
| filenames are an "exception", just as a start. It knows
| about lines but barely.
|
| PS has native json support.
| x0n wrote:
| Simply because on Unix, configuration is text files; bash
| and the gnu utils work with text. In Windows, it's an API
| driven O/S; powershell uses objects, but will coerce output
| to strings to allow text parsing if needed.
| sidpatil wrote:
| > most computer systems since the early 1970s
|
| How are you defining "most"? Back in those days there was
| much more diversity in the computing landscape.
| majkinetor wrote:
| Its far superior, like light years superior. PowerShell will
| exist, entire MS ecosystem is now based on it. That fear has
| passed years ago, especially when it got cross-platform. I
| expect actually to see more pwsh on linux and even OTB pwsh
| linux distribution (heck, I will make it myself if needed when
| I get retired).
| justsomehnguy wrote:
| > in the absence of Bourne-like shells
|
| I never had "Oh I would really liked to have *sh on this Win
| machine". Some GNU tools, like grep (just because findstr has
| it's own arcaneties) or sed - but neither of them is the part
| the shell itself.
|
| Sure, before 2012 if you wanted a little more flow control than
| provided by cmd you had not really many options (and if you
| needed portability you would need to use VB/Jscript, not a 3rd
| party tool), but since then you have PS3 at worst (on 2012/R2),
| or at least PS5.1 everywhere else, including client SKUs.
|
| And writing even not a complex script with a bunch of if..else
| is way, way easier in PS, be it for a Win or a *nix machine.
| bitwize wrote:
| PowerShell works on fundamentally different principles than do
| traditional Unix shells. Unix shells are for loosely coupling
| small "do one thing and do it well" programs. PowerShell can
| kinda do this, but its strengths lie in the "object streaming"
| features which aren't based on external processes at all but on
| loading .NET libraries with a special API, called cmdlets. In
| this respect PowerShell is a bit more like the VMS command
| processor, or using Python or Tcl as a shell. To add a command
| to a Unix shell, you need but drop an executable in your path.
| To add a command to PowerShell that takes advantage of
| PowerShell's features, you need to write a cmdlet in a language
| like C# and then install the cmdlet. This is also why
| PowerShell takes so long to boot up: it's probing for and
| loading installed cmdlets.
|
| For these reasons I do not consider PowerShell to be directly
| comparable to Unix shells, but it is an essential part of the
| Windows toolkit because no one wants to use the MS-DOS-like
| cmd.exe for anything serious.
| sterlind wrote:
| the latter, though I may have some Stockholm syndrome. killer
| features:
|
| * objects are streamed, not text. I look upon sed and awk and
| their ilk as stone knives and bear skins. why not just dot into
| fields?
|
| * first-class interaction with libraries. I can import managed
| DLLs and call their methods. I don't have to build weird little
| one-off tools or expose porcelain. I can get at everything,
| it's profoundly hackable in an un-Windows way.
|
| * the language is vectorized - basically like broadcast
| operators in something like NumPy. $x.foo gives you x's foo if
| x is an object, or an array of foos if x is an array of
| objects. it's really really nice.
|
| * separate commands in one binary and argument (sets) are
| first-class. there's consistent rules about what "-i" will be
| short for. personally, I can pull all the valid commands and
| arguments automatically into my accessibility software for
| voice typing. the whole standard "verb-noun" thing also makes
| commands be what you expect and discoverable.
|
| things I don't like include the language itself, its weird
| bindings to .NET (it predated the C# dynamic support and modern
| collection types), the restriction to .NET, bad support for
| streams (not sequences), the slowness, and the syntax looks a
| bit goofy. but it's worth the warts.
| at_a_remove wrote:
| I found -- when I last did anything in Powershell years ago
| -- that third point of yours to be incredibly frustrating. I
| wanted to iterate over a list, but sometimes I would get back
| a non-iterable solo object, or a None-like object, and my
| iteration would fail.
|
| I ended up doing a lot of testing to see what my returned
| results were.
| jasomill wrote:
| As with any large software project, there are at least few
| features in PowerShell that are confusing, inconsistent, or
| both.
|
| Auto-vectorization is one of them; usually it "just works",
| but can be a PITA when dealing with, e.g., pipelines
| returning sequences you'd prefer to keep separate.
|
| Another is that PowerShell error handling, while robust and
| powerful, can be difficult to implement properly,
| especially when "the right thing" isn't what PowerShell
| expects. Case in point: originally, PowerShell handled
| standard error output from external commands specially,
| wrapping lines of stderr output in error objects. While
| convenient in some cases, this made it unnecessarily
| difficult to work with external commands that output to
| stderr in non-failure cases, and was therefore changed in
| newer versions of PowerShell.
|
| A final, non-language example is cmdlet availability on
| non-Server Windows versions. While PowerShell _mostly_ has
| feature parity between desktop and server SKUs, there are
| at least a few non-Server-specific cmdlets that only work
| with Windows Server. The only example that comes
| immediately to mind is the ...-WindowsFeature set of
| cmdlets to manage installed Windows features; while present
| on client Windows systems, they fail with an error message
| unless the target system is running Windows Server. This is
| a particularly mystifying omission because dism.exe
| provides an equivalent command-line interface that works
| everywhere.
| polotics wrote:
| Cygwin has been a reliable features-complete alternative IMHO
| sidpatil wrote:
| How is Cygwin comparable? That's like saying Wine can be
| compared to cmd.exe.
| polotics wrote:
| Cygwin brings me a compatible-enough layer on top of
| windows that I can reuse scripts. It is comparable as it
| gives me a CLI, and to hen as it is not infected by
| Microsoftisms it gives me a warm feeling of safety..
| billti wrote:
| I love the idea of PowerShell, especially as scripts become
| more complex, having something closer to a "real" language
| and with decent debugger support is great.
|
| However it's just unintuitive enough, with enough sharp
| corners, to be a real pain. I find if I haven't used it for
| more than a couple weeks, then even doing trivial things
| require significant time and about a dozen browser tabs of
| docs.
|
| That said, trying to remember how to use the various *nix
| tools like curl, find, tar, etc. and wrap them in a bash
| script isn't easy either. No free lunch I guess.
| mjburgess wrote:
| I've often wondered why powershell hasnt taken off on linux/mac.
| I'd guess MS would have a good case for investing there (given,
| eg., linux usage on azure).
|
| Particularly in the recent history of "every day, another shell"
| on linux/mac. Powershell seems to solve the problem being
| resolved in rust,go,scala,... over-and-over. Why not just use
| that?
| randomifcpfan wrote:
| Would want to look at how people use Power Shell on Windows and
| compare to how people use bash/tools/procfs/Python/C on *nix.
|
| I think that, on *nix, Power Shell loses to cli
| tools/bash/procfs for trivial problems, to Python for simple
| problems, and to native strongly typed languages for
| complicated problems.
|
| Many Windows APIs are COM based, for both arguments and
| results, so an OO-based scripting language is helpful.
|
| Unix APIs tend to be less strongly typed. Mostly lists of lists
| of strings and ints.
|
| Is there really a recent increase in shells on Linux? I can
| only think of zsh and fish.
| syshum wrote:
| In mixed enviroments being able to use Powershell on both
| Linux and Windows allows for people to only have to learn one
| scripting environment, and allow you to share functions,
| modules, and tooling between the systems.
|
| that alone is a big WIN for PS imo
|
| Also I find Powershell to be more enjoyable to use (I like
| the verbosity, the help system, and passing objects instead
| of text streams.. I know I am crazy), and easier to train new
| Admins on PS than bash or python.
| Macha wrote:
| Debian moved to dash as the default shell a few years ago,
| nushell gets some users, fish has moved from niche to one of
| the big players, and yes, some people also use powershell on
| Linux.
|
| You could argue it's just a changing of the guard as things
| like csh or ksh die off on Linux and get fish/pwsh take their
| place as the second tier shells in popularity, but it did
| feel like many years we were in a bash monoculture with zsh
| only surviving by being sufficiently compatible.
| cobbal wrote:
| As a mac user, I was going to provide a flippant answer, but I
| decided to look into it instead. Personally, I use zsh or a
| custom built shell scripting library inside swift. Always like
| to see improvements to shells though. Googled for it and got a
| dozen guides on how to install it in mac, but none that
| actually explained how to use it. (One video result looked like
| it might have some info, but to me that doesn't count as
| documentation). All the documentation on powershell is targeted
| at windows devs, and it's just a very different culture.
|
| Flippant answer: the CapitalizationConvention-ShouldScare-
| EveryoneAway
| code_runner wrote:
| Imo your flippant answer is bang on
| nojito wrote:
| You really don't need any online documentation.
|
| Just use Get-Help and you're off to the races.
| CWuestefeld wrote:
| This, in conjunction with the cmdlets and their parameters
| being something approximating English, with semi-standard
| verbs, makes things a lot more discoverable than Linux
| seems to me.
| mjburgess wrote:
| Incidentally, I needed to teach myself PS for an azure-
| focused client of mine -- and I did so on mac (incidentally,
| making notes in a jupyter notebook with PS backend).
|
| It's a weird language, but I always reminded myself of its
| competitor: bash -- which is perhaps an order of magnitude
| more weird.
|
| It feels like it could be a "shell language for the cloud",
| ie., the language for cross-OS cloud automation work.
| vxNsr wrote:
| > _It feels like it could be a "shell language for the
| cloud", ie., the language for cross-OS cloud automation
| work._
|
| Isn't that terraform?
| BLKNSLVR wrote:
| Is it possible to "learn" Powershell?
|
| My very limited experience has been: look up problem, find
| likely solution, enter 60-character command specific to
| this niche issue that I'll only ever have to use again in
| this exact situation, which is now solved until next
| reinstall.
|
| Having said that, those are the only situations in which
| I've needed to use powershell.
| CWuestefeld wrote:
| To be fair, as a native of Windows, you seem to be
| describing the process I need to go through for stuff
| like maintenance of my home Plex server (which runs on
| Linux).
|
| I'd even argue that, between PowerShell's kinda-guessable
| commands and parameter names (as contrasted to
| bash/linux) and ubiquitous --help, PS makes it easier
| (relatively) to discover a solution on your own.
|
| I guess a big part of this is what your native language
| is.
| Macha wrote:
| > I'd even argue that, between PowerShell's kinda-
| guessable commands and parameter names (as contrasted to
| bash/linux) and ubiquitous --help, PS makes it easier
| (relatively) to discover a solution on your own.
|
| Yeah, if I'm trying to find something out on Unix-y world
| I have the escalation tree of
|
| 1. Tab Completion shows summaries
|
| 2. Still not clear? --help will usually print out an
| overview
|
| 3. Really still not clear? "man" to the rescue.
| chokolad wrote:
| there are wonderful books, that go deep into the
| language, or provide bunch of solutions to practical
| problems. Pick your poison:
|
| Powershell in Depth [1]
|
| Powershell Cookbook [2]
|
| [1] https://www.manning.com/books/powershell-in-depth
|
| [2] https://www.oreilly.com/library/view/powershell-
| cookbook-4th...
| oefrha wrote:
| I'm certain I once wrote a long rant about why I think the
| concept of PowerShell (using objects instead of text as
| interface) is interesting but it fell flat on execution and
| felt like something in the uncanny valley between *nix shells
| and Python/Perl, with a thousand papercuts. I'm not gonna dig
| that out, but to add some points I can remember at the moment
| to yours:
|
| - Write-Output and friends try to be smart and print
| different things situationally. I hate "smart".
|
| - Try to get something akin to set -e -o pipefail, i.e. exit
| if a command fails. Pain.
|
| - Try to get something akin to set -x for tracing. There's
| Set-PSDebug, but the trace level also applies to all the
| cmdlets, so say you use Expand-Archive, suddenly you have a
| million lines of crap in your trace you don't give a shit
| about.
|
| In general, IMO the biggest advantage of PowerShell compared
| to scripting languages like Python/Perl is the ability to
| natively interact with Windows' COM stuff. That advantage is
| nonexistent on *nix.
| smackeyacky wrote:
| And even the com integration is poor. Trying to script
| anything to do with Outlook is so failure prone and
| unreliable it turned me off powershell altogether.
| vladvasiliu wrote:
| I've actually installed Powershell on my Linux PC last
| year. I daily drive a Linux box, but I sometimes have to
| interact with my employer's MS ecosystem (that's
| technically not my job, so running Linux is fine most of
| the time).
|
| After waiting for the installation to do god knows what
| for what felt like ever (and I was running an 8 core Xeon
| with a fast NVMe drive at the time...) I attempted to
| connect to the Office 365 tenant to do something.
|
| Since it was my first attempt at running this on Linux, I
| was following along with the MS docs (actual docs.ms, not
| the TechNet circus) and I started getting uncomfortable
| with statements along the lines of "this should work". I
| mean, if you're not sure, who can be?
|
| Anyway, it managed to install whatever libraries it
| wanted, so I was ready to go. But everything ended
| abruptly with some "incorrect credentials" or similar.
| The credentials were, of course, OK (they worked fine in
| the web-based admin console). But after some digging, it
| turned out that, contrary to what the MS docs said, you
| can't connect to Office365 from linux...
| renox wrote:
| I agree that 'set -x' is the shell superpower, as it shows
| your scripts behaviour but not the inside of the tools you
| call.
|
| I'm quite sad that gdb doesn't have something similar:
| 'step in my application only' no I don't want to step into
| the STL shared pointer dereference implementation for the
| n-th time!
| wokwokwok wrote:
| Look, I've written a lot of powershell, and I don't mind it at
| all, but its not surprising at all to me.
|
| Powershell isn't in the same problem domain as
| rust/go/Scala/python.
|
| The niche it fills is "calling windows apis from c++" or, more
| recently, c#.
|
| It's less effort than that, so it's useful, on windows.
|
| It is not less effort than using say, a bash script on other
| platforms because it:
|
| - does not provide unique access to proprietary windows apis
| (they don't exist)
|
| - is not installed by default
|
| - does not conform to any standards other than it's own
|
| - no package manager that works
|
| The question you should ask is: why given that, would you,
| given that you must install something, choose to install and
| use powershell instead of python?
|
| There's no reason. You'd have to _specifically like powershell_
| to bother.
|
| Most people don't care enough to be bothered. Surprise level:
| 0.
| Siira wrote:
| Powershell is a shell. Shells don't do package management. Do
| you mean sth like ZSH plugin installers?
| digisign wrote:
| + telemetry-spewing ms products give some of us the willies.
| frogger8 wrote:
| Perfectly stated! Powershell is fantastic...for windows.
| Macha wrote:
| Also if you look at interactive shells, which have the lower
| bar to people trying them out (as seen by fish, nushell, etc.
| picking up users in recent years), powershell is actually
| quite clunky as an interactive shell. It doesn't appear to
| have completions matching those shells, the command names are
| quite tedious for those that don't have built in unix-y
| aliases, it doesn't provide a facility for common shell
| shortcuts like "run this one command with a modified
| environment", etc.
| juki wrote:
| > It doesn't appear to have completions matching those
| shells
|
| What kind of completions do you mean? PowerShell has
| completion for commands, parameter names and arguments. You
| can define arbitrary script blocks to do custom completion
| (or for simple cases just use `ValidateSet`). They can be
| defined either in the script/function itself, or separately
| with `Register-ArgumentCompleter` (that also works for non-
| PowerShell programs).
| Macha wrote:
| In fish, if I type ls -<tab>, I get a history based
| autocomplete suggestion (ls -l), and also a summary of
| options with brief descriptions: ls -l
| -1 (List one
| entry per line) -A --almost-all
| (Show hidden except . and ..) -a --all
| (Show hidden) -B --ignore-backups
| (Ignore files ending with ~) ...and 51 more rows
|
| I can use the arrow keys to cycle into the "and more rows
| section, or type further to narrow the list. zsh supports
| similar.
|
| In Powershell, if I type Get-ChildItem -<tab>
|
| It just cycles through options apparently abitrarily. The
| first suggestion is "-Path", and it offers no facility to
| provide explanatory information.
| juki wrote:
| If you use `Set-PSReadLineKeyHandler -Key Tab -Function
| MenuComplete` it will show the options and the types of
| the arguments, but yeah, I don't think there is a
| completion function available that orders them based on
| history or shows the docstrings.
|
| In principle there isn't anything that would stop one
| from making that. PowerShell has history info available,
| and help messages/docstrings can be given for parameters
| (`Get-Help command -full` will show them if available).
| nwallin wrote:
| I don't have any experience with iOS, and haven't scripted in
| anger in powershell.
|
| Linux and its ecosystem evolved alongside bash. If somebody
| tried to make a thing, and said thing was difficult to script
| with bash, nobody used the thing. They would say it's "hard to
| use". So system facilities and applications that don't script
| well with a shell script like bash (or csh or zsh to tcsh...)
| never survived.
|
| Basically, everything in linux automation is a nail, and bash
| is a very good hammer. DOS/Windows has had .bat scripts
| forever, which is not a particularly good hammer, but more
| importantly, Windows automation is very much not-nail like. You
| need a wrench and a socket set for many tasks, and CMD simply
| doesn't do that very well. (neither does bash for that matter)
| So powershell is a godsend. Meanwhile, us linux folks are
| sitting here with our hammer and all of our nails, and ...
| well, while I see that sometimes, it's maaaaybe nice to have a
| screwdriver as well, I certainly don't see the need for
| powershell.
|
| > Particularly in the recent history of "every day, another
| shell" on linux/mac.
|
| You'll note that all of these shells try to be a better hammer.
| None of them go in the direction that powershell goes in.
| archi42 wrote:
| wokwokwok, cobbal and oefrha made excellent points in the
| sibling comments.
|
| The only thing new PowerShell brings to the table is to pipe
| structured objects instead of only arbitrary data. And for that
| you don't need PowerShell itself: The power of the Linux shell
| isn't really the shell itself, it's in the powerful tools you
| can call from it and how you can interact with the Kernel and
| other components of the OS. The shell just gives you a simple
| interface and the ability to glue lots of small tools together.
| I think the reason we don't have a popular PowerShell clone, a
| "shell-with-objects", is that we would need to change how a lot
| of these tools handle basic data IO. I would love to see that,
| because sometimes parsing text is annoying, mental overhead;
| especially when filenames containing whitespaces are involved;
| but then there are always scripting languages waiting to help
| out (e.g. I tend to use perl kind of "super powerful shell
| script").
|
| Also, what's "every day, another shell"? I have been using bash
| nearly two decades now, with the odd script written for pure sh
| in case it might be shipped to a customer. After Manjaro duped
| my into using zsh (I think they changed the default) I am now
| growing fond of the improved completion and history; but I
| could still stick to bash without being on a deprecated track.
| WaxedChewbacca wrote:
| lloydatkinson wrote:
| Powershell runs on Linux and macos too because of .NET Core/5+.
| The real reason is likely the same sort of people that are
| still typing Micro$oft in <current year> and keep spreading FUD
| that .NET isn't OS.
| yebyen wrote:
| I have never heard anyone "spreading FUD that .NET isn't OS"
| but I have heard plenty of times from Mac and Linux users,
| "why would you want to use PowerShell" and I am mining this
| thread for answers, because I honestly don't know for myself.
|
| And it's objectively true that .NET/PowerShell is targeting
| Windows users, (which if you're Microsoft, why wouldn't you
| do that?) so, assuming that you don't care about
| interoperability with Windows users, don't use Windows
| yourself, don't have any customers asking for PowerShell
| support for whatever XYZ widget you build... what are the
| compelling reasons to run PS on Linux or Mac?
|
| Setting up .NET is an investment, and learning to program it
| is an investment, people invest in the Go, Rust, Ruby,
| Python, TypeScript, JS ecosystems because they are generally
| useful, and that extends to Windows people, but if I'm
| building a product targeting Mac or Linux (servers), what is
| the incentive for me to make my customers install the .NET
| runtime at the proper version and fiddle with .exe files (or
| am I completely off base about how it works?)
| lloydatkinson wrote:
| > I have never heard anyone "spreading FUD that .NET isn't
| OS"
|
| Observe /r/programming or HN for long enough.
|
| > .NET/PowerShell is targeting Windows users, (which if
| you're Microsoft, why wouldn't you do that?)
|
| Azure, for one. Azure's primary and preferred method of
| interaction instead of it's UI is with it's API, which is
| also available fully wrapped up as Powershell cmdlets which
| again run on all three OS's.
|
| > Setting up .NET is an investment, and learning to program
| it is an investment,
|
| > make my customers install the .NET runtime at the proper
| version and fiddle with .exe files
|
| You don't, you either get them to install it's APT .deb
| file or <insert distro packaging format here> or wget the
| dotnet-install script. OR, you just build your app with
| .NET runtime packaged in .so file alongside your app.
|
| Running the applications involves typing ./my-application
| which then runs the ELF binary. There is no .exe unless
| it's on Windows. It's the same install and run story that
| any of the other languages listed mentioned.
| yebyen wrote:
| > Observe /r/programming or HN for long enough.
|
| Well, I haven't seen those commenters before, and I'm
| still not excited about using .NET, (and I'm the type of
| person who you'd expect to be getting excited about a
| strongly-typed shell) so either that's not the driving
| factor here, or...
|
| > Azure, for one. Azure's primary and preferred method of
| interaction instead of it's UI is with it's API, which is
| also available fully wrapped up as Powershell cmdlets
| which again run on all three OS's.
|
| I have been getting into Azure, and I've found the `az
| cli` somewhat lacking, for example "why is the default
| 'get' behavior emitting a huge blob of JSON instead of
| printing a table that humans can read?" and I thought,
| maybe this is a reflection of the fact that they'd prefer
| you write an API client and build it into a portal for
| your customers rather than asking people on your team to
| use the CLI directly?
|
| Seems you've confirmed this for me here. It would be nice
| to use a strongly typed interface rather than parsing
| JSON blobs, maybe I will end up checking that out!
|
| Thanks :)
|
| > > make my customers install the .NET runtime at the
| proper version and fiddle with .exe files > > You don't,
| you either get them to install it's APT .deb file or
| <insert distro packaging format here> or wget the dotnet-
| install script. OR, you just build your app with .NET
| runtime packaged in .so file alongside your app.
|
| My point was, they do need to have or obtain the correct
| version of the runtime to go with your app, and if there
| are different apps with different maintenance cycles,
| that might mean you need multiple runtimes installed and
| a way of switching between them. That's a big deal!
|
| If I want to adopt a runtime, I hope I'm adopting it for
| more than just one app. Now all of these apps need to be
| on the treadmill, actively maintained, or some upgrade
| might break, pinning me to a particular version, and then
| I'm stuck.
|
| If there was ever a compelling problem to solve, it's
| here, although based on the breadth of languages and
| frameworks that still experience this problem in one way
| or another, I think it's likely unsolvable. You either
| need someone (a distro) running the compilers and
| checking that things still work together in concert with
| the maintainers of the upstream software, or you need to
| be statically linking, or get yourself something like
| venv/rvm that makes managing multiple versions of a
| runtime a low-overhead activity (so you can have 4
| versions if that is what is required for your different
| maintenance cycles across different services, without
| needing to break those services out onto four separate
| servers just to accommodate the language runtime
| differences.)
|
| Not to rule it out, does the .NET ecosystem have a great
| answer to this already?
|
| (Edit: I guess "the web application" is the answer,
| broadly speaking! "Users" don't have to install anything
| besides a browser.)
|
| > Running the applications involves typing ./my-
| application which then runs the ELF binary. There is no
| .exe unless it's on Windows. It's the same install and
| run story that any of the other languages listed
| mentioned.
|
| So I'm assuming you can also statically link your .NET
| binaries and emit a fat binary that will work anywhere,
| but at tremendous cost in terms of disk usage, (but you
| makes your choices and you takes your chances) - like I
| was saying, this is not a problem unique to .NET either,
| Go binaries from the likes of GCloud and Azure for
| interacting with their APIs are all enormous, because
| they want to avoid this problem with their users and they
| have lots of libraries to pull in.
|
| For me, the killer feature that makes Ruby ecosystem
| "worth adopting" is open source. You know how rare it is
| to encounter some Ruby gem which is not open to changes
| and inspection? I can think of exactly one time I found
| this, it did block me from using some software
| (AppDynamics bundled a native ext. with their Rubygem, it
| had wicked thread safety issues if you upgraded Ruby past
| a certain version... they did not provide the source, so
| enterprising customers couldn't fix the problem for
| themselves and contribute it upstream...) I've been using
| Ruby professionally for about 14 years, and I saw this
| issue exactly once.
|
| And that was a choice that one vendor made, and such a
| rare event that I would never think to let it reflect
| badly on the language. Go does not seem to have these
| issues as commonly (where somebody distributes a go
| package as binary-only) even though the language is not
| interpreted so it can happen and it wouldn't be unusual
| or even "against the grain."
|
| This is why I thought of Ruby being primarily executable
| as an interpreted language as "the guard" against this
| sort of thing happening in Ruby ecosystem.
| oaiey wrote:
| .NET is still ignored a lot as consequence of FUD. But you
| are right, there is not much FUD.
|
| The rest is spot on. Powershell has it space when you need
| manage windows and Linux Server using a shared platform.
| And that is where Microsoft puts it. As a .NET based
| management platform for services and operating systems on
| both, Linux and Windows.
| beagle3 wrote:
| My answer is: I've been using sh/csh/tcsh/bash/zsh/fish for
| almost 30 years at this point. I've used powershell on
| windows, and it's not bad, but it doesn't give me anything
| useful on Linux I don't already have with bash or zsh. And
| whenever a script needs more power, I reach for Python.
|
| (Maybe I should xonsh instead? But the question for me isn't
| "why not pwsh?" But rather "why pwsh?")
| jmull wrote:
| The actual real reason is *nix had mature shell scripting
| many years before powershell was conceived.
|
| For powershell to "take off" on non-Windows platforms, many
| people need to adopt it and for many people to adopt it, it
| needs to solve some critical problems the existing solutions
| don't solve well.
|
| I think pretty clearly, powershell doesn't do that.
|
| (I think I personally would be an easy candidate to use it on
| Mac... I know/use powershell pretty much daily at my day job
| -- so there's a minimal learning curve and I still haven't
| seen any reason to use it on various Mac side projects and
| jobs. I just do bash/zsh scripts. If it was built in maybe
| I'd reconsider.)
|
| For myself, I know powershell reasonably well from my day job
|
| Sometimes people will switch to something new just because
| it's new, but for , generthe new thing has to have some
| recursive wrote:
| Title has a typo: It's "Snover".
| MandieD wrote:
| There are probably several thousand, if not more, other former
| Windows platform admins like me that are absurdly grateful that
| Snover stuck with his vision, giving us a path to being
| automation and, later, cloud experts. I've since branched off
| into DevOps, but up to about 2011/2012, was pigeon-holed as a
| Windows admin. Doing a few clever things with PowerShell and
| Active Directory led to my being chosen to work on my company's
| Skype for Business deployment, then Azure, which led to
| Kubernetes and DevOps.
|
| Having an immediate work-related reason to learn a powerful
| scripting language means a lot in particular for people who don't
| have a lot of time to learn things outside of work, like parents
| (especially mothers) of young children.
| omega3 wrote:
| I find this twitter thread frustrating.
|
| Q: What was the justification for the demotion? What became of
| the leaders that made that decision?
|
| A: It was stranger than you can possibly imagine
|
| I think the gist of the story is that he was assigned to work on
| X but worked on Y instead. Notwithstanding how great Y idea
| turned out to be it seems he was demoted for insubordination?
| qbasic_forever wrote:
| IIRC powershell came about in the mid 2000s when it was the
| peak Steve Balmer and Windows Vista era for Microsoft.
| Absolutely none of the senior leaders at that time survived at
| the company in the long run, at least no one in the Windows
| organization. Jim Allchin, Steve Sinofsky, etc.
| EnKopVand wrote:
| > it seems he was demoted for insubordination?
|
| Probably, and what management blunder that would have been if
| Jeffrey had left Microsoft because of it.
| phkahler wrote:
| They would never have known. When you cook the goose, you get
| a nice meal but you never know about the golden eggs that
| never got laid as a result. Everyone thinks they did the
| right thing except for the goose.
| HWR_14 wrote:
| Yeah, but almost always geese lay regular eggs. You cannot
| just never kill geese in the offchance one lays golden
| eggs. The maintenance costs get astronomical.
| gumby wrote:
| This is why gold is expensive and you're simply
| justifying the injustice
| [deleted]
| phkahler wrote:
| Agreed. I was responding to the question of whether the
| cook ever realizes the mistake. Of course he doesn't -
| particularly if it's a new cook or someone who thinks
| geese are fungible.
| jodrellblank wrote:
| > What became of the leaders that made that decision?
|
| @Dejify: _Not sure if you can speak to this, but it 'd be nice
| to know what happened to those who dinged you?_ -
| https://twitter.com/Dejify/status/1523025584749629440
|
| @Jsnover reply: _" Retired"_ with a picture of Donald Trump on
| the Apprentice captioned "Fired" -
| https://twitter.com/jsnover/status/1523031601390571520
| tjoff wrote:
| Twitter threads are frustrating no matter the content, after
| two replies I get a banner that blocks me from reading until I
| register.
|
| Not gonna happen.
| beagle3 wrote:
| Nitter is your friend if you care (while it lasts).
| Nitter.net or nitter.eu usually work for me.
| _Microft wrote:
| Using Nitter is as easy as replacing twitter.com with e.g.
| nitter.net or .eu:
|
| https://nitter.net/jsnover/status/1523010444570419200
| dredmorbius wrote:
| This particular "thread" is simply two tweets.
|
| There's no explanation of why the demotion occurred, by whom,
| for what reason, when rescinded, etc., etc.
| tjoff wrote:
| Ok, even that was obfuscated for me.
| jodrellblank wrote:
| Click on the banner to login, the page will change to a login
| form with an [X] close button; click that to cancel and
| you'll be returned to the content to scroll a couple more
| replies until it tries again and you get bored.
| Sinidir wrote:
| use nitter.net instead.
| EdwardDiego wrote:
| Yep, I'm doubly less likely to sign up when you pull that
| crap.
| qbasic_forever wrote:
| Firefox in a private browser window seems to get past the
| registration popup for me. You have to close and reload the
| private window periodically because it somehow starts to
| fingerprint you as a user and starts showing the popup after
| some time.
|
| If there's a way to configure a specific site to never ever
| store any cookies or send them under any circumstance that
| might be the next thing to try. Make twitter think you're
| friggin curl. Unbelievable we have to do this nonsense just
| to read the site.
| [deleted]
| Jemm wrote:
| So the implication of the title is that Powershell is being
| embraced and loved. Not sure I love it personally Wonder what HN
| thinks?
| GartzenDeHaes wrote:
| I wonder if this was some kind of corporate camouflage. EVERYONE
| LOOK, WE ARE DEMOTING JEFFREY, cool stuff you're doing, keep
| doing it.
| throwawaymanbot wrote:
___________________________________________________________________
(page generated 2022-05-08 23:02 UTC)