201–210 of 221 posts
Earlier quoted context omitted.
No, the one with history going back more than an hour, and tab completions on anything except files in `pwd`.
that's basically what conemu brings
ConEmu is not a shell, so it does not provide "shell features" like tab-completion, command history and others. [1]
Earlier quoted context omitted.
> They also are both designed to glue together independent programs via the pipe abstraction PowerShell and its object pipeline are focused on cmdlets which are not arbitrary programs, they are .NET classes, and PowerShell objects are .NET objects. Unix shells like sh and bash are focused on tying together separate programs and only have a very minimal set of built-in commands. The focus of each one is very different…
> PowerShell and its object pipeline are focused on cmdlets which are not arbitrary programs, they are .NET classes, and PowerShell objects are .NET objects. Both correct and horribly wrong. PowerShell is indeed focused on cmdlets (and functions) and it's pipeline concept is focused on objects. It is also correct that cmdlets are not arbitrary programs. However, cmdlets are not .NET classes. It is true that you can i…
They are instances of .NET classes that derive from `Cmdlet` and `PSCmdlet` and run in the PowerShell runtime. As stated plain as day in the Microsoft cmdlet documentation:
"Cmdlets are instances of .NET Framework classes; they are not stand-alone executables."
Your entire comment is an attempt to obfuscate the nature of PowerShell cmdlets, which are actually very simple.
>> Piping objects between cmdlets in PowerShell is analogous to working with objects in Python, Ruby, Perl, etc, not like Unix pipes.
> No it is not.
Yes it is.
This is not about the term 'pipeline,' it's about how PowerShell, Unix shells and pipes, and language runtimes work and the scope to which they apply. FACT: PowerShell's object pipeline is internal to the PowerShell / .NET runtime, just as other language features of Python, Ruby, etc are internal to those languages' runtimes. FACT: Unix pipes are primarily for chaining separate processes. They are a lower-level feature than the runtimes of Python, Ruby, or PowerShell, and can be used to chain those runtimes together with each other and other processes.
Here's an illustration of the scope of each one.
PowerShell's cmdlet / object pipeline:
(PowerShell runtime)
(Python runtime) | (arbitrary executable) | (PowerShell runtime) | (Ruby runtime)Earlier quoted context omitted.
> PowerShell never just works. That statement is a bit much. I agree the default execution policy is annoying, but can you blame MS for being a little overzealous given their history? Some aspects of Powershell are actually pretty nice. Ever want to use a real hashmap in bash for example? Or easy JSON construction/manipulation without hacks like jq? PS has all that.
I have had so many people tell me how fantastic PowerShell is. Not a single one of them was ever a *nix user. PowerShell is getting better with a tab completion of sorts but it is still a headache to figure out commands without web search. I try to force myself to use PowerShell as often as possible, but continuously find myself going back to a GUI. I have the opposite problem when using Linux.
Want to know what you can do with network adapters? Run Get-Help AD to see every cmdlet containing AD, and narrow your search from there.
Get-Help auto-updates itself. See a command, but want to know all of the ins and outs (syntax etc) of using it? Run Get-Help [command]. Use the optional -Examples flag to see several well-explained examples. You can even add -Online to get the technet article to launch in your default web browser.
I would think that nix users would feel at home with powershell. Microsoft has made a big push for getting developers to take a second look at Windows. They even set up aliases for common nix commands. Don't type 'dir', just type 'ls' - It works fine.
Earlier quoted context omitted.
It takes 10 seconds to restart Windows these days, so it's almost analagous.
Do you have any benchmarks to support that claim? I have Windows 8 and 10 systems which take minutes to reboot on an SSD which beg to differ.
https://www.youtube.com/watch?v=p_vUZR2RtRs
https://www.youtube.com/watch?v=xkKoggifsE4
(And you don't need to log in for your background services to start.)
Earlier quoted context omitted.
I can't believe in 2015 PuTTY is still a thing. Other platforms have a half dozen terminal programs, three of which are usually very good, and Windows has one that looks like it was hacked together on a weekend in 1998.
It's an ssh client. It is robust, easy to install and it works well. How much energy do you expect me to waste evaluating and choosing new ones when the one I have works just fine the way it is? I have better things to be doing.
Linux in particular is filled with "well enough" solutions that should be striving to be better. Although there's misfires when controversial things like systemd happen, there has been steady improvement in other areas. Imagine if Nginx had never happened, if NCSA httpd was "good enough"?
The Windows user base deserves better than PuTTY.
I was going to say, "Finally! They've gotten it right after all these years of sucking so hard as to be unusable on servers." But, I did some digging into the github for OneGet ( https://github.com/OneGet/oneget )... And, they haven't gotten it right. Windows package management still sucks so hard as to make the OS unusable on servers (and annoying as hell on the desktop). This is seemingly a simple-minded downloader…
package management is going to suck on windows as long as permissions sucks on windows. multiple times, i've been unable to delete my own damn files as administrator on windows machines, leaving me angry and frustrated. i've also been stuck in a catch-22 in the extended acl/permissions dialogs, unable to exit. all the googling in the world couldn't help me - it was just fuckin' broke. sane package management can't ex…
It has been about ten years since I maintained some Windows installation packages for a reasonably large project (originally built with a proprietary package builder when I took it over from the previous maintainer and then I ported it to build using a fork of the Python MSI builder). So my understanding of Windows package management and the pains of making things work reasonably is weak and out of date. So take this guess with a grain of salt. I might even be describing what happens and why wrong I dunno...I avoid working on Windows as much as possible, so my ignorance is high.
I can really only speak to the comparison of OneGet to apt or yum, which is absurd on its face. And, I have observed the interesting level of denial that kicks in whenever criticism is leveled at an OS based on weak package management. There's always a lot of "well, I just do this ridiculously unwieldy thing and pretend like it isn't a ridiculous and unwieldy thing to do, so I don't see why I would want something like apt or yum". This tread has been no exception. It's like I'm insulting them personally when I say the workflow they are having inflicted on them by their OS is suboptimal.
Earlier quoted context omitted.
Do you have any benchmarks to support that claim? I have Windows 8 and 10 systems which take minutes to reboot on an SSD which beg to differ.
You can see it when you do a video search for: Windows fast boot. Here are a couple: https://www.youtube.com/watch?v=p_vUZR2RtRs https://www.youtube.com/watch?v=xkKoggifsE4 (And you don't need to log in for your background services to start.)
Worse, the conversation was actually about the time needed to install updates. Now that Windows logs out before installing updates, you have a fairly sizable time delay – tens of minutes after a large update even on an SSD – while the service is unavailable but before the system starts rebooting.
How does Fast Boot work? Well, it's actually not booting at all – it's logging out all active users and hibernating:
http://blogs.msdn.com/b/b8/archive/2011/09/08/delivering-fas...
That's a really nice bit of work in normal usage but it means that you have to do the standard cold boot process when you're getting a system update. That means that a sysadmin would need to review each update to know whether it would trigger a fast or slow boot, assuming that a patch for e.g. SQL Server wouldn't always trigger a cold boot to be conservative.
The alternative is what everyone's been saying, namely that you have to assume that a reboot is slow and have n > 1 servers if uptime matters.
Earlier quoted context omitted.
I have had so many people tell me how fantastic PowerShell is. Not a single one of them was ever a *nix user. PowerShell is getting better with a tab completion of sorts but it is still a headache to figure out commands without web search. I try to force myself to use PowerShell as often as possible, but continuously find myself going back to a GUI. I have the opposite problem when using Linux.
I think this comes from being unfamiliar with it. Want to know what you can do with network adapters? Run Get-Help AD to see every cmdlet containing AD, and narrow your search from there. Get-Help auto-updates itself. See a command, but want to know all of the ins and outs (syntax etc) of using it? Run Get-Help [command]. Use the optional -Examples flag to see several well-explained examples. You can even add -Online…
This presumes that the developers' first look and decision to stay away from Windows was mistaken. It wasn't.
I avoid Windows because mistakes were made. If Microsoft continues to assert that I'm the one who made the mistakes, then I'm just going to keep avoiding their stuff.
As a developer, I make dependency choices based largely on my confidence in the upstream's judgment. Microsoft has a long track record of making poor technical decisions and then never fixing them. I've also heard enough about their internal culture to understand how difficult this would be to change. Introducing a shell or a package manager well over a decade after it was clear that they needed one doesn't inspire confidence.
Not to mention Microsoft's tendency act coercively when they can get away with it, and friendly when they can't. Yes, I'm bitter about this.
I still don't plan on taking a second look.
Earlier quoted context omitted.
As long as there is no single prevalent native package format for Windows, packaging is going to suck on Windows. That's why this tool exists, but I don't think attacking a big mess with more complexity is the right approach. I hope I'm wrong, but I think this will end up 'successful' only in the way NuGet is 'successful' - there's not really any competition. What I'd hoped for is that MS would commit to extending MS…
Wait. Are you saying that MSFT is going to walk away from the everything-and-the-kitchen-sink installer format that is MSI? This is actually (seriously!) a bit surprising to me!
"To achieve these benefits, we removed the GUI stack, 32 bit support (WOW64), MSI and a number of default Server Core components."
Earlier quoted context omitted.
Wait. Are you saying that MSFT is going to walk away from the everything-and-the-kitchen-sink installer format that is MSI? This is actually (seriously!) a bit surprising to me!
http://blogs.technet.com/b/windowsserver/archive/2015/04/08/... "To achieve these benefits, we removed the GUI stack, 32 bit support (WOW64), MSI and a number of default Server Core components."
It would be absurd to think that MSFT would ever drop support for the GUI in every version of Windows Server. :)