Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Linux kernel hidden inside Windows 10

github.com

Post reply on HN
Print view View original

51–60 of 166 posts

Re: The Linux kernel hidden inside Windows 10

#51

Post by [deleted] »

wangchow wrote: post #32
Amezarak wrote: post #29

Earlier quoted context omitted.

Which is really unfortunate. I can't blame Microsoft for it, but the app-gap between WP/WinMo 10 and Android is getting untenable for me. I'm thinking about switching back, not because I think Android is better (I don't think it is at all), but simply because I'm starting to feel left out when all my family and friends are using, e.g., SnapChat to keep in touch and I...can't. It particularly riles me up that there we…

Honestly I use the app-gap as a feature. Not having the fluff is great because snapchat is making people illiterate. We went from real words to abbreviations to no words and minimal attention span. On the other hand now that Uber and bank of america have a universal app it feels more complete.

[deleted]

Re: The Linux kernel hidden inside Windows 10

#53

Post by GeorgeHahn »

sdrinf wrote: post #31
Zardoz84 wrote: post #28

Earlier quoted context omitted.

And there is some strange behaviour with the keys. Actually using LXSS become far lees powerfull to the users of Conemu thanks to this. Vim and NeoVim does weird things with the arrows, on mc I can't navigate on the filesytem with the cursors, and htop does weird things.

I suspect that might be conemu, and compatibility thereof. Specifically, running the bog-standard bash prompt (with conhost.exe) makes this a no-repro; all keys / arrows works in MC & htop

Unfortunately, it appears to be a design problem on the Microsoft side: https://github.com/Microsoft/BashOnWindows/issues/111#issuec...

Re: The Linux kernel hidden inside Windows 10

#54

Post by criddell »

satysin wrote: post #41
Mahn wrote: post #34

Earlier quoted context omitted.

That's a shame. I mean, I get the concern, but full Android compatibility would have done wonders to adoption, which is what their phone platform desperately needs. They could have always lured developers later with a substantially better UWP on top of it.

I don't believe it would drive adoption at all. Microsoft know Windows Phone today is dead. However they still have the desktop and with UWP they hope to bridge the development gap between mobile/tablet/desktop/laptop. Had they shipped Astoria in Windows 10 to allow Android apps to "just work" it would have destroyed their UWP strategy. So they might get a few more Windows Phone users but they would have lost control…

> Had they shipped Astoria in Windows 10 to allow Android apps to "just work" it would have destroyed their UWP strategy.

Kind of like how OS/2 support of Windows applications helped destroy it?

Re: The Linux kernel hidden inside Windows 10

#55

Post by jhoechtl »

wangchow wrote: post #32
Amezarak wrote: post #29

Earlier quoted context omitted.

Which is really unfortunate. I can't blame Microsoft for it, but the app-gap between WP/WinMo 10 and Android is getting untenable for me. I'm thinking about switching back, not because I think Android is better (I don't think it is at all), but simply because I'm starting to feel left out when all my family and friends are using, e.g., SnapChat to keep in touch and I...can't. It particularly riles me up that there we…

Honestly I use the app-gap as a feature. Not having the fluff is great because snapchat is making people illiterate. We went from real words to abbreviations to no words and minimal attention span. On the other hand now that Uber and bank of america have a universal app it feels more complete.

Why the downvote? This is a legit and conscious comment

Re: The Linux kernel hidden inside Windows 10

#56

Post by makomk »

cm3 wrote: post #17
jacobwg wrote: post #3

Earlier quoted context omitted.

GitHub will actually render a full preview on the website, no download required. https://github.com/ionescu007/lxss/blob/master/The%20Linux%2...

Github uses pdf.js for that, so it's not more or less secure than viewing it with Firefox's built-in viewer.

There have been serious security issues with the integration of pdf.js into Firefox in the past, so it may actually be more secure than Firefox's built-in PDF viewer.

Re: The Linux kernel hidden inside Windows 10

#57

Post by colechristensen »

allendoerfer wrote: post #12

I wonder how much further humankind would have progressed by now if "because it can be done" were not such a big motivation for intelligent people. Edit: Since everybody took this post seriously, I will, too: We would be closer to some local maxima, but would have no chance to progress beyond them.

From fire and agriculture to airplanes and the moon landing, a huge portion of human development and the entirety of fundamental science wouldn't have happened at all if they demanded some preconceived idea of immediate utility. So, I like to reserve this thing for rare occasions, but straight up fuck you for trying to force your own ideas about usefulness to how other people spend their productive time.

Re: The Linux kernel hidden inside Windows 10

#58

Post by jimsparkman »

So far, this has been fantastic. Our team has been seriously considering converting from Windows to Linux for embedded development. (we run Linux VM when needed) Up and running and cross compiling for ARM without issue. Really surprised how it has just worked so far. This came at a great time for us.

Re: The Linux kernel hidden inside Windows 10

#59

Post by wilun »

sdrinf wrote: post #37
rrdharan wrote: post #33

Earlier quoted context omitted.

> unix processes are not aware of windows ones; nor have I found any ways to send signals backwards I haven't tried it out, but this project claims to offer support for doing exactly that: https://github.com/xilun/cbwin/

| Note that outbash.exe listens on 127.0.0.1, but validates that processes that establish a connection are running as the same user as outbash.exe (this check is implemented starting with version v0.7). Therefore, it can be used on multi-user computers. (from: https://github.com/xilun/cbwin/ ) So, I suspect this uses TCP & networking to do that; which does work: you can listen to a port in LXSS, and that will be acce…

I confirm it only uses TCP for all communications between Win32 and WSL; source: I wrote cbwin. For now there is no other documented API, so this is the only sane choice (actually you can also use temp files on the FS, but it would be a poor idea for several reasons)

Using TCP is actually not that much different than opening a Linux or Windows device or IPC object and using it, except that: * you must handle serialization and framing, * you typically get no security for free (I get some back with a GetExtendedTcpTable + OpenProcessToken + AccessCheck hack), * performance is not excellent, esp with the security check, however on a modern computer you can still sustain launching at a mean rate of ~40 Win32 process / sec (and peak rate of hundreds per sec), which is largely enough for any use case I expect. (Actually if you do spawn Win32 process too fast for too long, Windows tends to graphically bug even after you stop that activity. It might be because of my graphic card driver, because I did not had that issue in a VM.)

On the plus side of using TCP, I could easily test some of the WSL side code on a real Linux to track some bugs (temporarily allowing non localhost connections on my dev environment)

To be clear, cbwin is not and will never be a complete substitute to proper IPC / interactions between Win32 and WSL, but that's not too much of an issue because MS will very probably add some in a future release -- I think at least some way to launch Win32 programs from WSL, and at least working pipes between processes of both world (not 100% sure, but I would be surprised if they don't).

Re: The Linux kernel hidden inside Windows 10

#60

Post by whyenot »

kragen wrote: post #38
whyenot wrote: post #25

Earlier quoted context omitted.

Of course Microsoft then licensed XENIX to the Santa Cruz Operation which after several years renamed it to SCO Unix. SCO eventually split apart, but the piece that ended up with SCO Unix renamed themselves the SCO Group. The SCO Group with (possibly indirect) financial backing from Microsoft, attempted to use XENIX in a number of copyright infringement lawsuits to attack Linux vendors.

Hmm, there are a variety of inaccuracies in your short statement. Please carefully read the below so that you can be protected from propagating these errors in the future. · SCO Unix, although it incorporated some Xenix code, was very different from Xenix; it derived a lot from SVR4. · SCO basically went out of business, because their value proposition was "Unix, but on a regular PC so you don't have to buy an expens…

I appreciate your critique, but stand by my original statement. Let me address the items you bring up point by point. Please excuse my brevity.

1. Xenix was based on Bell Labs V7 and then AT&T SVR2, SCO Unix was based on SVR4. Xenix and SCO Unix shared code in addition to that derived from their common ancestry. Claiming that they were "very different" is obviously a matter of opinion. In my opinion, they were pretty similar.

2. SCO split into two pieces: one was sold to Caldera, the other became Tarantella. As far as your hypotheses about why SCO failed, I'm not seeing why it is relevant to the discussion.

3. Microsoft indirectly backed SCO Group through BayStar capital. Please verify this for yourself with a quick web search so you will be protected from propagating your misinformation in the future.

4. Not relevant.

5. Both XENIX and SCO Unix were derived from the same original codebase. SCO Unix would not exist if it were not for XENIX.

6. Actually, I think the AutoZone and DaimlerChrysler lawsuits are fairly unimportant within the context of the original discussion. To me, the interesting point is that MS had the foresight in 1979 to see that Unix would become a big thing and as a result created Xenix. Decades later, when Unix (Linux) was indeed a big thing, by proxy, it attempted to use XENIX to fight back at Unix (Linux) proponents.

Post reply on HN