yokohummer7

You're not weird. PowerShell does have barriers to entry and that's why I also had used Cygwin on Windows until recently. And it might not change because it is a very different monster than POSIX. It is unfortunate for sure, but still I think it's worth learning especially if you use Windows frequently.

Even if you don't, learning it is a fun experience. It's like learning Haskell just to feel another way to program, even though you're not using it in practice.

It is not only ugly but also slow. One of the pain points while using PowerShell. It seems that Microsoft didn't care much about the emulator until recently. Thankfully things are changing, it was improved a bit in the Windows 10 anniversary update and Microsoft promised to improve it further. I'm optimistic about it.

:( Why is it not the default? Is there a technical reason? I cannot think of any possible downside that the shortcuts would bring.

> On the other hand, if Windows had a proper shell and cli tools, like cygwin with zsh, but native and not Ubuntu layer inside - that would be tremendous.

It is PowerShell, and it really is. Until recently I thought Windows had poor CLI support, and I discovered PowerShell and now I favor it even more than bash.

Am I crazy? Possibly, but PowerShell is truly a piece of gem in the CLI history. It is a thoughtfully crafted product regarding what "command-line interface" should look like.

> It's terrible to script

I'm pretty sure you didn't try PowerShell. It is at least as good as bash, if not better.

> you need to use the mouse too much

I find this more problematic on macOS. I was forced to use a mouse much more on macOS. It doesn't even allow me to press the yes/no dialog only using a keyboard. On Windows nearly every item has a shortcut, sometimes even better than GNOME (but worse than KDE, IMO).

Actually I liked that feature. We used to chat with each other using it when I was in school. It was definitely a right choice for Microsoft to disable the Messenger service, but I was a bit sad when it actually happened.

It may sound crazy, but I did suffer from it myself. My Windows XP installation was guaranteed to be infected by the worm, because like you said, without any interaction (I didn't even open up the browser, to make sure I was not crazy), the Blaster worm was often sent from somewhere in the Internet during the installation procedure. Even if it wasn't, there was not enough time for me to run Windows Update before my computer being infected, because the infamous "your computer should restart now" message always displayed several minutes after the installation was done. So back in the days, I always made sure to turn off the DMZ before reinstalling Windows XP.

You could check how frequent the attacks were by yourself. I was using a custom firewall software, called ZoneAlarm, to see how many attacks I was receiving in a day. The log said literally every few minutes, the infectious Blaster worm packet was received. It was like how frequent your SSH server is attacked with random passwords - you can see this from the SSH server log too.

  a:not([href])  
  a[href="#"],  
  a[href=""],  
  a[href*="javascript:void(0)"] { … }

Wait, what should I use instead then?

That's interesting, I've always thought the WebSocket spec is too complicated with all those frame types and message fragmentation, and I completely ignored contunation frames when I had to implement the protocol myself. But it seems more versatile than I imagined. Though the workaround you mentioned sounds a bit hacky.

And yeah, I now remember that masking was also a problem at the time. So even if web browsers adopt a new API to send fragmented messages, it would still not be possible to directly plug in them to legacy servers. Sad.

Edit: It would also be possible to send a single giant message, which contains a single giant continuation frame sent for the lifetime of the session, which is followed by a FIN frame. Am I correct?

Yeah, but both parties can leverage the existing connection without resorting to a message-based protocol, can't they? They could just assume they're now sending and receiving bytes after the upgrade.

What I meant when I said "utilizing the legacy TCP sever" was creating some plugin that is attached to the server, effectively acting as a lightweight HTTP server that just does the upgrade process (within the same connection). In this way the remaining communication doesn't have to involve message encapsulation/decapsulation each time a message is transferred.

> Websites would be able to launch DDoS attacks by coordinating UDP packet floods from browsers.

> New security holes would be created as JavaScript running in web pages could craft malicious UDP packets to probe the internals of corporate networks and report back over HTTPS.

Is this the same reason that the "raw" TCP is not supported on the web? When I first learned WebSocket I was surprised that it is a message-based protocol. What I imagined was a protocol that utilizes HTTP only as a means of negotiation, and the actual transfer is done just as the raw TCP does. But it's not, so I had to create another layer to be interoperable with the existing (raw) TCP server. What was the exact reason?

Edit: Another reason I can think of is the encoding issue, cause TCP is byte-based. But the current WebSocket spec already assumes UTF-8 for textual data, and is also capable of sending bytes using `ArrayBuffer`. I don't see how this would matter in practice.

Probably a bug report with the most duplicates?

> The x87 FPU was originally designed in (or before) 1980. I think that's why it is quite simple: it has only one unit for all FP data types. Of course, the precision must be of the widest type, which is the 80-bit long double.

> Consider you have a program, where all the FP variables are of the type double. You perform some FP operations and one of them is e.g. 1e-300/1e300, which results in 1e-600. Despite this value cannot be held by a "double", it is stored in an 80-bit FPU register as the result. Consider you use the variable "x" to hold that result. If the program has been compiled with optimization, the value need not be stored in RAM. So, say, it is still in the register.

> Consider you need x to be nonzero, so you perform the test x != 0. Since 1e-600 is not zero, the test yields true. While you perform some other computations, the value is moved to RAM and converted to 0 because x is of type "double". Now you want to use your certainly nonzero x... Hard luck :-(

> Note that if the result doesn't have its corresponding variable and you perform the test directly on an expression, the problem can come to light even without optimization.

> It could seem that performing all FP operations in extended precision can bring benefits only. But it introduces a serious pitfall: moving a value may change the value!!!

TIL long double is a thing.

Well, just by looking at a glance, kqueue seems to pose similar problems. I mean, the problem mentioned in the OP:

  1. Kernel receives some data, and wakes up A
  2. A reads some data
  3. Kernel receives some other data, and wakes up B (cause A didn't call `epoll_wait` yet)
  4. B reads some data, leading to a race condition (out-of-order reading).

kqueue's `kevent` seems to be more or less similar to `epoll_wait`, in that it doesn't seem to provide a way to notify the kernel the "we're done" signal. Am I missing here? Does `kevent` also signal the end of the exclusive access?

So, the kernel is free to assign a connection to a new thread even if there is a previous thread working on it? Because the kernel has no idea when the previous worker will be done processing the data. So the user has to manually unregister and register the connection each time?

How about a concept like "transaction"? Maybe such as `epoll_begin` and `epoll_end`? One thread achieves exclusive access when entering the block, and releases it when leaving.

Does this flaw also exist in IOCP or kqueue?

Funny, it seems that, by the standards of the OP, the fork you mentioned is not "Python 2" either. It backported type annotations, async/await, and many more from Python 3. So when are we expected to see a "true" Python 2 fork? :)

Might be an off-topic, but recently I learned that Windows does come with a C# compiler. It's included in the .NET runtime, which is installed by default nowadays. This might be useful if you're extremely lazy to install any language implementation. It is quite amazing since even Ubuntu doesn't ship a C/C++ compiler by default.

> I mean technically its closer to my target production environment than macOS is.

Huh, I didn't think about that, but you're right. Yeah, I won't have to deal with slightly different shell tools that are bundled with macOS. I'm not saying those tools are bad, it's just that I'm so used to GNU tools. Also, the directory structures and the kernel interfaces will exactly be the same as Ubuntu. Good point.

One thing I find odd about the display is that it somehow changes white balance occasionally depending on the content. I'm not sure if this only happens on BootCamp or not, but it's a bit surprising. Is there any setting to turn off this?

Oh wow. I can't believe I didn't think of it earlier! As a Vim user I've always been told it is good to swap Caps Lock and Esc, yet I haven't actually tried it due to my laziness. Probably now is the time.

And Windows Subsystem for Linux! While all my server and development stuffs are based on Linux, I wasn't particularly a fan of the Linux GUIs. The reason MacBook was attractive was that it runs POSIX. But now Windows can do that too thanks to WSL. It's not complete but even the current partial support does enough for me. It's a cheap, lightweight alternative to Linux VMs. I guess I would go with a Windows-based laptop next time. It is truly a game changer.

Well, my experience is the opposite: while using the new MacBook I realized how infrequent I was using the function keys. The only times that I noticed the "missing" function keys were when I tried to open up the web developer console (F12), or rename a file (F2). I did see Apple's rationale here: ordinary users won't miss them, given I, being a developer, didn't miss them either.

But unlike you and the OP, pressing the Esc key did affect me. I couldn't completely get used to the soft key even after using it for more than one month (currently). Every time I try to press Esc, I'm a bit hesitant. The inertia was higher than I expected. So I can't agree with the phrasing that "there is no justification for the apparent panic." The annoyance exists and I'm the living proof.

> Google Authenticator stores the key unencrypted in an sqlite database, which you can look at if you have rooted your phone.

Interesting, actually that's exactly the reason why I like the TOTP algorithm over other two factor mechanisms. I can see what my private keys are, I can back up them, and I can even copy them to other phones I maintain.

Some would tell me it's not good for security, but I'd like to manipulate them in the same way I manipulate my SSH keys. It's just so convenient. If they are moved to TrustZone or something I'd be massively upset.

One of the reasons why many people come to HN is that it gives the moderation that is not covered by laws.

When they say the privacy issues of Windows I see a double standard. Android is, to my mind, equally "invasive" as Windows, if not more. Except the fact that Android's source code is open, they are pretty much same regarding end user experience. Yet every time Windows 10 is brought up people say privacy.

Yeah, I understand that Windows wasn't like this, so people can get upset about the recent changes Microsoft is pushing onto. On the other hand Android has been like that from the beginning, so there might not be much expectation. But still I don't care Windows-as-a-service because nowadays pretty much every software I use is provided like that. It's just that the OS becamse not an exception.

I have zero knowledge about microcontrollers, so forgive my dumb question... But how do you program with 16-byte RAM!? I believe even ENIAC had more memory than that? (Though I'm not sure if ENIAC had such a concept like main memory.)

What useful thing did you conduct with it?

Isn't the license concern pretty major though? IIRC even in the current form Wine at the early age had been quite controversial, due to legal concerns. They consciously prevented those who have knowledge of Windows internals from contributing to it just to make sure it's a clean room implementation.

> Unless you think Rob Pike is saying that Google is hiring mediocre programmers (hint: he's not), that statement is intended as a criticism of academics ("researchers"). He's saying that the same things that excite researchers about programming languages don't lend themselves to good software engineering in industry. (And he's right).

If that was the case, it was a very dubious thought. Before Go was launched, the languages used in Google were Java, Python and C++. None of them look academic, none of them seem to require another language that is specifically designed to "unexcite" newcomers. Neither is functional, really.

I was thinking more about the "proper noun" aspect of the UNIX commands. I mean, what do `awk`, `sed`, `tar`, `xargs`, `df` mean? Why does `free` only print the remaining memory, not the disk space? Why is `top` even related to processes? They are all like that because Unix has had a long way until today. In the beginning `grep` would have been enough, but suddenly someone wanted to improve the state of affairs, and made a new command named `awk`. Probably there had only been `ar`, and then later the necessity of `tar` was found. `free` is not `mf` and `df` is not `free`, because the original designer thought the free space of the main memory was more important. All these inconsistency/idiosyncrasy do make learning the UNIX command hierarchy harder. We developers don't feel that way because we all are very used to such commands, but there might be some memory in our inside when we tried really hard to memorize all of the useful commands just to do basic things.

PowerShell didn't have this backward compatibility concern so it built up its own vocabulary from the scratch. While it is nowhere near to perfect (as your example shows, the VERB-NOUN naming scheme can be a bit cumbersome when some functionalities need to be grouped), I'd say it is at least much more consistent regarding basic file/device management, because there was simply no baggage to consider when they designed PowerShell for the first time.

Ah, and thanks for suggesting `Ctrl-Space`! I thought it would have been better if PowerShell had a GUI widget listing possible candidates, so I was considering sending a patch. It turns out that the MS people are definitely more clever than me. :)

Well, how about this:

  ls . -r -file -fi *.html | cp -d /home/new_dir/

It is a bit shorter than your bash equivalent, still doing the same thing.

I think you're mistaken about what `cp` (`Copy-Item`) is intended to do. Its main purpose is to copy, not to filter. Yes, `Copy-Item` supports filtering because it's part of the "common parameters", but to be more in line with the cmdlets' original purposes, you should `ls` (`Get-ChildItem`) first, because it has more filtering capability, and then pipe the results to `cp`.

Is it complex? No, actually its complexity is exactly the same as that of your `find` example! `find` is more or less equivalent to `ls` in that both gathers the list of files that meet certain criteria. And then, like `find` invokes `cp` multiple times to do actual copying, `ls` (`Get-ChildItem`) feeds its result to `cp` (`Copy-Item`). They are structured in a similar way.

I'd even say the PS one-liner is more akin to "the UNIX philosophy". In the bash one-liner, there is a direct parent-child relationship between `find` and `cp`, which doesn't utilize pipes at all. Whereas the PS one-liner connects two equivalent processes (`ls` and `cp`) with a pipe. This is exactly what I'd call "small processes work together to get the job done", which is again the UNIX way.

I had been a full-time Linux (desktop) user for more than 10 years, and only recently made a transition to Windows. As I'm nowhere proficient at using PowerShell I might be overrating it a bit, as the grass is always greener on the other side. Anyways, what I found to be satisfying while using PS were:

1. The input/output is done using objects. I know that "inter-process communication should be done with text" is the UNIX philosophy, and I appreciated that when using Linux, but after using PS I started to have mixed feelings about that. When using bash/zsh, I typically used awk to extract the data I wanted from the text emitted by an external process. Doing so isn't hard, mostly as simple as using `awk {print $3}` or something like that, but it is still a bit annoyance and more importantly, vulnerable to the changes in the output format.

PS cmdlets communicate with themselves using objects, so it is very easy to extract some columns out of the command results. For example, when I query about a process in PS:

  PS> Get-Process -Name chrome
  
  Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
  -------  ------    -----      -----     ------     --  -- -----------
      362      80   169636     109896  36,411.16    484   1 chrome
      497     113   274988     132544   5,161.00    656   1 chrome
      404      84    87444      55356     303.56    764   1 chrome

If I want to extract CPU time and process ID:

  PS> Get-Process -Name chrome | Format-Table -Property cpu,id
  
           CPU    Id
           ---    --
  36441.265625   484
    5163.09375   656
      303.5625   764

Let's see what processes consumed the CPU most!

  PS> ps chrome | sort cpu -descending | select -first 3
  
  Handles  NPM(K)    PM(K)      WS(K)     CPU(s)     Id  SI ProcessName
  -------  ------    -----      -----     ------     --  -- -----------
     1186     317  1876160    1055016  88,462.64  10524   1 chrome
     1023      88  1825008     668684  37,740.92   6128   1 chrome
      362      80   155776      64560  36,848.00    484   1 chrome

As you can see, I can simply specify the column name(s).

This is probably why many Linux commands have detailed options to limit displayed information. For example, `uname` has -s, -r, -m, -p, and many others that are just portions of -a. If it were in PS there would be no other options than -a and users could utilize it accordingly. Likewise `ps` has many options just to control the output which is again not necessary in the PS's side.

Also due to the probable scripts that may be reliant on the column orders (e.g. my script assumes the third column to be always the one I wanted, because I hard-coded `awk {print $3}` in there), it is very hard to change the layout of the output in Linux commands. In PS there is no layout in the first place, so this backward compatibility concern doesn't exist.

2. Command names are much clearer. Many names are pretty descriptive so I don't have to remember the exact abbreviated forms, but at the same time they provide shorter aliases. For example `Get-Process` can also be called `ps`. bash/zsh can also benefit from this by manually assisning aliases, but I believe "sane defaults" should be long-descriptive names first, and abbreviated forms later.

3. Much more objected-oriented design. Say for example you want to get the last modified date of a file. In Linux I'd use `stat` and somehow extract information from it. Or, `stat` may have some option to print mtime so I may have to google for it. In PowerShell, I can use this instead:

  $file = Get-Item C:\Windows\notepad.exe
  $file.LastWriteTime

This also applies to the process example above:

  $processes = Get-Process -Name chrome
  $processes[0].CPU

All of these are benefited by tab completion, so you can easily find what properties any object has. This greatly improves discoverability, so that I don't need to rely on documentations (man pages on Linux, MSDN on Windows).

Not only that, but PS is much closer to a general-purpose programming language than bash/zsh. It has built-in calculations (no need to rely on expr/bc), and it even has some basic type safety, such as:

  PS> 1 + 2
  3
  PS> 1 + "a"
  Cannot convert value "a" to type "System.Int32". Error: "Input string was not in a correct format."
  + 1 + "a"
  + ~~~~~~~
      + CategoryInfo          : InvalidArgument: (:) [], RuntimeException
      + FullyQualifiedErrorId : InvalidCastFromStringToInteger

which might be silently ignored in bash/zsh in most cases. As you can see it even has fixed-width integer types (Int32), which is rarely seen in dynamic languages!

When the logic of my scripts got complicated, I tended to abandon shell scripts and start programming in Python. But after learning PowerShell I'm starting to have a confidence that typical workflows can be implemented in PowerShell, in a readable way. I even think that PS can be utilized as a general-purpose programming language, like, "Python without dependencies", because PS is installed by default on Windows nowadays.

Whoa, my response got unintentionally huge O.o. Hope this helps anyone.