230 karma · joined June 18, 2015
But yeah, it's even fully integrated into NixOS options now. You can set up a default install with one line: https://search.nixos.org/options?query=photoprism
Intro to Programming 1 and 2 were taught in C++. Can't remember which one taught pass by reference, but it was definitely in one of those two.
Third class I took was Intro to Systems or something like that. The whole class was C and x86 ASM. Lots of binary operations in that one, used K&R a fair amount in that class (also learned debugging assembly in GDB and some other "low-level"-ish stuff).
Just looked it up, can't say 100% it's still C++, but the syllabus looks about the same as I remember for both class. It gets to pointers by week 7, and then in the second class goes deeper:
* https://web.cs.ucla.edu/classes/spring22/cs31/syllabus.html#...
* https://web.cs.ucla.edu/classes/spring22/cs32/syllabus.html#...
And again, I didn't even get a CS degree. This was all lower-div CS work at a public university, and I'm not even a career engineer.
> So no, not knowing the difference between passing references or values, or pointers and dereferencing them is not as strange as you seem to think it is. It is not a piece of knowledge or experience that is seen as valuable enough by the people that create the curriculum or the companies that employ the largest quantities of inexperienced workers in this part of the world.
This attitude is why you're getting flak in this thread. Your claim that "We don't teach pass by reference these days" was too absolute, and not accurate for a ton of people. Then someone came back and told you that, and you told them that their claim was too absolute.
I'll also say that it's something that was absolutely valued around the orgs I worked in at Microsoft (Azure, DevDiv, Windows, very roughly bottom half of the stack teams). If not C/C++ pointers, than __absolutely__ passing by reference in C#.
Point being: __knowing__ about pointers, passing by ref vs. value, etc. is not as strange as __you__ seem to think it is.
It's intended as a shell semantic where anything bare on the command line just gets run, no matter your scope.
However when we introduced classes, we thought it was a more "dev-oriented" semantic, so we changed return there.
This will only return 'this will return':
class foo {
[string] ReturnTest() {
'this will not return'
return 'this will return'
}
}
([foo]::new()).ReturnTest()Our setup today is simply to add an apt repo[1] (of which there is just one domain for all Microsoft Linux packages), and then you can `apt install`.
We also ship pretty minimal Ubuntu and Debian (and Alpine and a bunch of other) container images here.[2]
Oh, and we ship on the Snap Store if you're using Snapcraft stuff.
If you're seeing issues within PowerShell 7, please file issues against us at github.com/powershell/powershell
I don't know how recently you've tried PS7, but the back-compat (particularly on Windows) is much, much better[1]. And for those places where compatibility isn't there yet, if you're running on Windows, you can just `Import-Module -UseWindowsPowerShell FooModule` and it'll secretly load out-of-proc in Windows PS.
Unfortunately, the .NET problems are outside my area. I'm definitely not the expert, but I believe many of the decisions around the default assembly load context are integral to the refactoring of .NET Core/5+. We are looking into building a generalized assembly load context that allows for "module isolation", and I'd love to get a sense in the issue tracking that[2] whether or not fixing that would help solve some of the difficulties you're having in building modules.
For Azure, you should check out the PSArm[3] module that we just started shipping experimentally. It's basically a PS DSL around ARM templates, as someone who uses PS and writes the Azure JSON, you sound like the ideal target for it.
As for the help content, that's a very funny story for another time :D
[1]: https://aka.ms/psmodulecompat
I'd love to get more of your thoughts around how PowerShell might be more useful for the kinds of scenarios you're thinking about. We see a lot of folks writing portable CI/CD build/test/deploy scripts for cross-platform apps (or to support cross-platform development), but we're always looking to lower the barrier of entry to get into PowerShell, as it can be quite jarring to someone who's used Bash their whole life (myself included).
Structured shells have so much potential outside of that, though. I find myself using PowerShell to "explore" REST APIs, and then it's easy to translate that into something scripted and portable. But I'd love to get to a place one day where we could treat arbitrary datasets like that, sort of like a generalized SQL/JSON/whatever REPL.
Plus, PS enables me to Google regex less :D
And we're "just" a language runtime and a shell shipped in the OS. I can't imagine how hard it would be to unwind the proprietary bits of something like a GPU architecture running in a tightly integrated SoC with multiple vendors who are all deeply protective of their IP.
I say this all as someone who has been a proponent of open source for 15 years. And all the work was absolutely worth it, and deeply rewarding from a personal perspective.
But I can't say it would probably make the same sense for Nintendo to go through that effort with Pokemon or the N64 architecture.
But also, lots of folks prefer an object-oriented pipeline. Many of those folks (our primary use case for 10+ years has been IT management) are used to PowerShell on Windows and starting to learn or be exposed to other environments.
We've also got lots zsh-style optimizations in PSReadline. In some cases, we've got some catching up to do, but there's also lots of unique interactive optimizations hiding around[2].
It's also great for interactively exploring REST APIs and building scripts via that experimentation. Try running
Invoke-RestMethod [or irm] https://api.github.com/.
Store that as a variable:
$a = irm https://api.github.com
And then look at all the properties you can explore:
$a | Get-Member [or gm] $a.<tab><tab><tab>
Oh, and of course, one of the big reasons is "so you don't have to open a Windows VM to remote into your Windows Server boxes and manage them from a Macbook".
This is obviously not an exhaustive list, but it'd take a lot more time to write about every benefit and scenario here. In any case, it turns out that our user base is pretty spread out among different scenarios, but between our repo and usage numbers, we've been really happy with how excited that such a diverse group of folks really love PowerShell.
And feel free to reach out to me on Twitter @joeyaiello if you ever want to talk more about your experience (or just hop into our GitHub repo). :)
[1] https://aka.ms/PSGitHubBI [2] https://docs.microsoft.com/en-us/powershell/module/psreadlin...
THIS is the one that comes into play. All that stuff you listed before is a slog to go through when you go to open-source, but unless you're parking the thing as a proof-of-concept/end-of-life, you're now signed up for maintaining the repo. That means triaging issues, pull requests, helping out when contributors don't understand why their build is breaking, etc.
And there's the PM aspect of it: you don't just want to develop a bunch of features without talking to your community, so communicating (in a public friendly way) what you're planning to work on, when folks might reasonably expect that, how they might be able to help out, which of their contributed features you might be able to take depending on where you're at in your lifecycle, and RESPONDING TO COMMENTS all takes way more time than just "building [closed-source] product" in a team of 5-20.
And of course, one of the hardest of all: telling people "no, we can't take that change" when they've spent hours and hours doing work for your project for free. In that regard, we're still very much iterating on a transparent design process that allows for consensus BEFORE too much work has been done (though as we all know, building prototypes is often one of the best ways to find out if a design works right or not).
If you're doing it all right, everyone involved in the project should be doing some amount of all of this every single day. There's no compartmentalizing an engineer on an OSS project as "someone who just writes feature code" vs. "someone who does the repo stuff".
So going back to OP's point: no, it doesn't literally "cost anything" (or very much) to do the basic act of open-sourcing, doing it the "right way" at scale where you're truly engaging and working with the bazaar is very expensive.
Full disclosure: I'm a PM at Microsoft working on PowerShell and was heavily involved in it being open-sourced and ported to macOS/Linux.
I'm a huge privacy advocate, but telemetry doesn't have to be a dirty word. With PowerShell Core, we went through an RFC process to define our telemetry goals and implementation[1], we publish our data to a public dashboard[2], and all of the telemetry source code is out there in the open[3]. Our telemetry enables to help drive prioritization and decisions around platform/OS usage, and disabling it as simple as setting an environment variable[4].
If there are any other ways we could make our telemetry implementation more palatable without seriously reducing its usefulness, we're absolutely open to suggestions.
[1]: https://github.com/PowerShell/PowerShell-RFC/issues/50
[2]: https://aka.ms/psgithubbi
[3]: https://github.com/PowerShell/PowerShell/blob/master/src/Mic...
[4]: https://docs.microsoft.com/en-us/powershell/scripting/whats-...
In this light, it's important for me to recognize that you could easily see me as someone falsely claiming imposter syndrome, even if I know I'm not.
Not sure it helps with the imposter syndrome, though...
I would highly recommend you check out the excellent HistoryPx module[1]. Among (many) other things, it supports automatically saving the most recently emitted output to a magic `$__` variable. Theoretically, you could save a lot further back, but you may start to run into memory constraints (turns out .NET objects are a little heavier than text... ;) )
I haven't seen DomTerm before, but it looks pretty awesome. At a glance, it's basically a GUI-fied tmux hosted in Electron? It would be awesome to have in Windows, but wouldn't that just require that DomTerm add support for these ConPty APIs?
In any case, I'm more interested in your proposed interactions. Did you have anything cool in mind? Given that we ship PowerShell on Linux, we could theoretically do some stuff there (including within PowerShell on WSL) before it's hooked up to ConPty
PS C:\> cd hkcu:
PS HKCU:\> ls -r | ? name -m 'HeidiSQL'> I miss that time in my life.
Me too. I'm still in my 20s, but given that I now have a lot more means working in the tech world than I had when I was a teenager, I've been thinking a lot about how I might be able to help foster communities like that for younger generations (opening a venue, starting a small label, patronizing high school bands that want to record, etc.) Curious if you've thought about the same?
EDIT: Holy crap, just realized you're the subject of the article. Definitely didn't mean to imply you didn't play a role, FYI, but I imagine you played a large part given your humility on the matter. ;) Keep up the good fight, man. We're rooting for you.
924 Gilman had none of that. I remember the first time I saw this sign[1] and then realizing that there were no security guards to enforce those rules. And yet, the punk ethos was strong enough that folks were just generally good to each other.
Or the graffiti all over the walls with a graffiti code of conduct posted every so often: don't tag over color with black and white, don't put doodles over real art, that sort of thing. Sure, it wasn't 100% followed, but people really respected it for the most part.
Or the 25 cent bottles of water and cans of soda. No profit, just kids handing out there zines and making sure no one goes thirsty.
Anyway, I'm going to go finish the article now, but if this guy got 924 Gilman, and wants to take that ethos into the internet, I couldn't be more supportive. Godspeed.
[1]: https://www.flickr.com/photos/61992100@N03/23226226149/in/al...
Personally, for quick interactive stuff, I just `ls` when I'm sitting on a non-Windows machine. My finger muscle memory just does `ls -al` and `rm -rfv` when I'm sitting on a Linux box.
But if I need to do some heavy sorting/filtering, I'd much rather save the minutes wrestling grep/awk/sed/xargs than save the minutes on execution (or the hours on having just done some operation based on some grep/awk/sed/xargs work that I didn't properly test).
That being said, yeah, I also want tabs. In the meantime, I switch back and forth between conhost and Cmder. :shrug:
If you grab our GitHub bits, we compile against LibreSSL there, and you should see LibreSSL showing up in future Insider builds of Windows. That brings support for all the other crypto algorithms you'd expect (RSA, DSA, etc.)
Those builds will also be showing up in Insider builds over the next few weeks (if they haven't already).
If you mean, "interact with them from an interactive shell like cmd or PowerShell", yes, you can absolutely do that. Our implementation literally stands up a console host on the server side, so whatever you can do in that console host with the privileges you have, you can do over SSH.
If you mean, "do you support SCP and SFTP for transferring files in a network-drivey way" the answer is also yes. SCP is supported directly against sshd, and we ship both an SFTP server and client.
If you're talking about something NFS or SMB related, I'd be curious to hear more details.