Wine on Windows 10 | Hacker News Reader

Wine on Windows 10

reddragdiva.dreamwidth.org

386 pointsfanf2130 comments

This can be very helpful in the future for playing games with strange 16-bit-mixed-with-32-bit installers that fail to run properly on modern Windows, even 32-bit versions. I hope WSL2 comes out soon.

Now that installing wine in Linux on windows is possible, the next step becomes clear. We must compile and run cygwin on wine in Linux on Windows.

Exactly. I used a similar approach to install Space Empires III on a Windows 10 x64 machine which would not run its 16bit installer but would run the 32bit game itself just fine.

Does WSL work on wine ?

Maybe by using qemu? (Windows on qemu on Wine on Linux on Windows)

No. WSL is a part of the NT kernel (part of their modular architecture, quite cool to read about) and can't be replicated with an alternative program loader like Wine. You'd need to run a whole new copy of the kernel to get a second instance of WSL, which can already be done through virtualization.

Nope. WSL is basically a reimplementation of the Linux kernel's syscall layer (or at least the original version of it was - WSL 2 is an actual Linux kernel running in a VM). If you do a Linux syscall from within a Wine app it calls into the actual underlying Linux kernel and Wine itself makes heavy use of this within its libraries. WSL on Wine isn't possible and doesn't really make sense. I guess it might be possible to add support for WSL 2 since that's just a VM, but I'm not sure why you'd ever want to since it is just a VM.

This project is only completed when you can recursively keep doing this forever, without it ever breaking.

Any CPU can only have one hypervisor running at a time. Thus the recursion stops pretty quick.

Cygwin and Wine don't use virtualization. And even if they did, most hypervisors support nesting these days.

Because, of course, its not a emulator

Why? There's only one hypervisor involved for the initial "wine" environment.

Neither WINE nor WSLv1 use virtualisation. WSLv2 does use virtualisation however; but WINE still isn't a VM.

I was referring to WSLv2 here, so technically there is a hypervisor involved at the root level hosting the first WINE instance in the chain.

Further recursion WINE => Cygwin => WINE however will not require more nesting of hypervisors.

Actually most modern hypervisors allow nested virtualization.

https://www.linux-kvm.org/page/Nested_Guests

https://communities.vmware.com/docs/DOC-8970

Not even just modern hypervisors. The IBM mainframe hypervisor z/VM (and its predecessor VM/CMS) has supported nested virtualisation for decades. It was an important tool to support its own development (especially considering that mainframes were expensive and not even IBM could afford to give every mainframe OS developer a whole mainframe to themselves.)

Well, yes and no. On modern enough hardware you can do nested virtualisation, so you can run kvm in esxi on hyper-v if you want. Not that it's very usefull, but it is a fun weekend project nonetheless.

I use nested virtualization for Windows Desktop -> Linux VM -> minikube. Works great.

Obviously you could just run minikube under Windows, but then from the Linux VM you can't "minikube ssh" and whatnot, so nested virtualization makes everything a lot simpler.

You can even do nested virtualization without hardware support, it's just super duper slow and not a lot of hypervisors think it's worth the complexity increase.

Intel and AMD CPUs have supported hardware-accelerated nested virtualisation for quite some time now.

https://docs.microsoft.com/en-us/virtualization/hyper-v-on-w...

https://www.redhat.com/en/blog/inception-how-usable-are-nest...

WSL1 is not a "real" VM. https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process...

Aside from all the other corrections, hardware virtualization support isn't necessary for virtualization.

We know how it would look like! Here is a nice illustration:

https://m.xkcd.com/1764/

That's a thing already: http://git.annexia.org/?p=supernested.git;a=summary

I tried following those steps and got this error:

https://www.betaarchive.com/imageupload/1299034742.or.31168....

Does anyone know of a workaround?

To tie this back to Wine, here is what we actually do during some parts of the Proton[1] build process: Run a Debian 9 VM, inside of which we run an Ubuntu 12.04 Docker container (the Steam runtime), which runs an Arch Linux chroot in order to gain a modern cross-compiler. It's a doozy[2]!

[1] Proton is Valve's fork of Wine which ships with the Linux Steam client.

[2] https://github.com/ValveSoftware/Proton/commit/d68e71bed61c8...

May I ask why you need that many distributions? It really looks interesting.

Debian 9 for the Vagrant VM, because it was modern at the time (probably upgrading it to Debian 10 soon). Ubuntu 12.04 because that's what the Steam runtime uses, because it was modern at the time and upgrading while maintaining binary compatibility is Hard. Arch Linux because building a modern cross-compiler on Debian/Ubuntu is Hard.

What, did you want good reasons? :)

Out of curiosity, since you might know: is Proton upstreaming changes or are they going their separate ways?

I'm not informed enough to say whether the fork made sense or not, but my immediate reaction was that using a OS project with immense man hours and effort behind it for commercial gain without contributing back would be very ... questionable.

Yes, of course. Valve is a very good open source citizen. The fork was necessary because we have a fair number of changes that are not appropriate for upstream Wine. As a single example, we integrate closely with the Steam for Linux client for stuff like achievements and multiplayer, which obviously can't go upstream. I'm actually the guy who does the rebases, so I'm very motivated to keep the diff as small as possible :) You might find this article from March interesting: https://www.codeweavers.com/about/blogs/aeikum/2019/3/27/how...

Thanks, that's great to hear!

Thanks for the amazing work you guys are doing! I'm keeping an eye on the progress and it's amazing to see: https://boilingsteam.com/proton-keeps-making-its-way-in-comp...

Have you seen The Birth and Death of Javascript? https://www.destroyallsoftware.com/talks/the-birth-and-death...

You can already do that with OTVDM: https://github.com/otya128/winevdm

Using it not only any 16bit installer works, but also most 16bit applications. As an example you can play Exile by Spiderweb[2] on your Windows 64 PC.

It even contains a .reg file that allows it to be installed system-wide so that you can run a 16bit .exe just by double clicking it in Explorer (or any other file manager).

[1] https://github.com/otya128/winevdm

[2] http://www.spiderwebsoftware.com/exile/winexile.html

Looking at the install.inf file, I saw that they first remove a key from the registry with the name VDM in it. So I wondered what VDM means.

> Virtual DOS machines (VDM) refer to a technology that allows running 16-bit/32-bit DOS and 16-bit Windows programs when there is already another operating system running and controlling the hardware.

https://en.wikipedia.org/wiki/Virtual_DOS_machine

So how come otvdm is needed I wondered.

Same Wikipedia article explains it.

> NTVDM is a system component of all IA-32 editions of the Windows NT family since 1993 which allows execution of 16-bit Windows and 16-bit / 32-bit DOS applications. It is not included with 64-bit versions. The Windows NT 32-bit user-mode executable which forms the basis for a single DOS (or Windows 3.x) environment is called ntvdm.exe.

But why did Microsoft not include VDM in 64-bit systems? I thought MS was all about that backwards compatibility.

MS is already running a similar system to translate 32-bit applications to 64-bit mode (WOW64). Keeping compatibility with 16-bit would have big consequences for the NTVDM. The alternative would be to run NTVDM on top of WOW64 but such a system would be a recipe for disaster.

I don't think the compatibility with 16-bit systems is worth the headache/expense. As long as 32-bit Windows exists, you can still run the few relevant and compatible DOS applications so I doubt anyone is missing much aside from a few nostalgic gamers.

>I doubt anyone is missing much aside from a few nostalgic gamers.

There's tons of 16-bit SCADA stuff in the world that it would be nice to not have to run on a ~20yo version of windows.

Aren't there still 32-bit versions of Windows 10? AFAIR only the server versions are 64-bit only by now.

Installing 32-bit OS on a 64-bit UEFI system can be a problem.

I hope those scada systems aren't running on regular Windows. If they are, they should be running on Win10 LTSB on 32-bit so they should keep working till at least 2025 if XP's level of compatibility was good enough to run them.

If they can't be run on that, there's still MS-DOS licenses being sold and FreeDOS might also serve them in a pinch. If a system is not maintained for long enough that it's still running in compatibility mode, you might ask well just disconnect the network cable and run Windows 3.11/95/98. Microsoft is not at fault for the manufacturer not maintaining their systems.

What if the manufacturer doesn't exist anymore?

Or you're using hardware from the 70s that they dropped from software support in the 90s and the software version you need won't run on anything newer than Win2k.

In that case you either were aware of the risk of your device breaking down in the future and have started looking into migrations or workarounds the moment the news hit, you took the risk that didn't happen and now have to deal with the consequences or you just didn't plan ahead enough.

Just keep running the older version of Windows that worked with the device. Add a couple of layers of configurations, firewalls, VPNs, traffic monitoring and whatnot inbetween to reduce the risk and don't connect the device to the internet. Your solar panel farm doesn't need to access Gmail or run Windows 10.

Your obscure SCADA device is your responsibility. The switchover to 32bit had been announced 20 years ago and the switchover to 64bit 10 years ago.

Also, if the manufacturer doesn't exist anymore, where are you going to source replacement parts?

Virtual 8086 mode isn't available when running a 64-bit OS, so the virtual DOS machine code simply won't work there. This is less of a problem with most 16-bit Windows applications since the limited 16-bit functionality they need is still possible under a 64-bit OS but making this work requires some extremely hairy kernel code.

You could just run it in an emulator. And microsoft has written a virtual 8086 emulator for virtual PC. Virtual 8086 mode was just a virtual machine anyway.

NTVDM used to contain an x86 emulator included for running DOS programs under Windows NT on non-x86 platforms (Alpha, MIPS, PowerPC). There is no reason in principle why they couldn't have used that existing code on x86-64. But, I assume they decided that the cost of doing that (in developer time/etc) wasn't worth the benefit. (Running DOS programs has little commercial relevance any more, and the small minority who still have a need for that are better served by more fully-fledged virtualisation solutions such as Hyper-V, VMware or VirtualBox.)

AFAIK including the full VDM wasn't technically possible due to amd64 architecture limitations (no real mode support when in long mode - at least not without use of virtualization but that wasn't a thing at the time). They probably could have implemented partial support but i guess they wanted to keep the full VDM for 32bit versions of Windows (which were the majority for a good number of years anyway and thus more important for backwards compatibility).

OTVDM emulates a 386-ish CPU so it isn't affected by that (i think there is also some code to use virtualization instead but i'm not sure). It is much slower though, but it should still be much faster than the target hardware that 16bit Windows applications had. Perhaps it might be an interesting project to port DOSBox' more advanced JIT CPU emulation code to this.

Playing Exile 2 is exactly why I want to run 16 bit applications. I basically learned English from that game! I remember being frustrated being locked into the shareware version by Shareware Barriers, figuring out how to edit maps by using Norton Disk Edit on the game files, and digging new tunnels into the cave wall. I was about 12 and I still consider this my greatest hacking achievement...

You are in luck then, all three Exile games are free from the site :-) (you need to dig a bit to find them, go to the games, then old games then click on the icon for the windows version).

> you need to dig a bit to find them

Should not be a problem, seems user has been digging for Exile since he was 12

Now I just need to find the old tileset that looked like it was hand drawn in MS Paint to maximize the nostalgia!

> As an example you can play Exile by Spiderweb[2] on your Windows 64 PC.

How is this of all things the go-to example?

It's exactly what I want to do! Were these games more popular than I thought?

For the time, yes. They were free, and they were Ultima-alikes, and those were popular. JV has always also had a knack for writing, which helped make them stick.

He's still making games, and they're still pretty much the same games they were--and to me that is a positive.

> Now that installing wine in Linux on windows is possible, the next step becomes clear. We must compile and run cygwin on wine in Linux on Windows.

That would be so awesome! :)

If you are a desperate bastard like me, you can install it with Windows build 18917 as described here : https://devblogs.microsoft.com/commandline/wsl-2-is-now-avai.... Caveat: I have not done it, but hopefully will do it during the weekend.

This is why I think we will always be able to run all software ever, just keep on piling up older virtualizers (or api translators).

I feel like it would be useful to add "(using WSL)" to the title.

I admit I would not have opened the link though, had the title spoiled this part of the story, and the article is funny to read.

> Running Wine on Windows has been a fever dream of those responding to the siren call of "we do what we must, because we shouldn't" since at least 2004, when someone tried compiling Wine in Cygwin and trashed the registry of the host system.

[…]

> But I want to stress again: this now works trivially. I'm not some sort of mad genius to have done this thing — I only appear to be the first person to admit to it in public.

WSL is part of Windows 10, so I didn't feel the title was leaving out something important.

Well, you are right but I expected to find an article speaking about Wine running on native Windows without WSL, which would make it interesting in another way.

I would not expect Wine not to run on WSL. What I learned from the article though is that WSL1 does not run 32 bit binaries (and that someone botched their registry trying to run Wine on Windows back in 2004, which I found funny).

> Well, you are right but I expected to find an article speaking about Wine running on native Windows without WSL

While it isn't all of Wine, it is a fairly well-known usecase to build certain Wine modules and run those on Windows. It's been used to support ancient games that depend on certain old quirks that have changed in more recent Windows. It's also used by graphics driver developers, because Wine's implementation works on both Windows and Linux, so they can study differences at the driver level on both platforms.

Hilarious. Props to author for not trying to give a reasonable looking motivation for this beyond "It would be funny". That's more than enough.

  Physics is like sex: sure, it may give some practical 
  results, but that's not why we do it.

-Richard Feynman (disputed)

Didn't know that quote but it's amazing how it applies to many things. Fixing something in the house for instance.

But there is a reasonable motivation. Some old games and some other software often don't run well on modern Windows (or sometimes at all). It can be possible to patch them to work but not always and even this relies on motivated and talented fans.

OP here: you and I both know that's an excuse, and the actual reason is "because we can and shouldn't"

If MS is now serious about cross-platform compatibility (and they have been moving in that direction), they should consider building a bridge over the filesystem divide as well. One or more of these would be useful:

- Shipping a ext4 filesystem driver for Windows.

- Contributing to exfat/ntfs drivers for Linux/Mac OS.

Both would be even better.

Allegedly WSL2 allows you to access things in the WSL file system from plain Windows programs. In 5 minutes of experimenting I could not get a JetBrains IDE to work on a project stored in the WSL filesystem. You can at least use Windows explorer now though.

I use WSL just about every day and I'm very optimistic about its future.

Was writing about filesystem drivers. They're not tied to WSL, but rather improve interoperability.

OP here! Someone commented with how to make i386 work: https://reddragdiva.dreamwidth.org/607714.html?thread=831766...

not just qemu-user, but telling it the magic numbers for binfmt to work

I'll give it a spin when I get home this evening. ENCARTA 97 SHALL RIDE AGAIN, maybe

Looks like the same procedure from

https://stackoverflow.com/questions/42120938/exec-format-err... (second answer)

Thanks to my anonymous commenter, we have a route to 32-bit:

sudo apt install qemu-user-static

sudo update-binfmts --install i386 /usr/bin/qemu-i386-static --magic '\x7fELF\x01\x01\x01\x03\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00' --mask '\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xf8\xff\xff\xff\xff\xff\xff\xff'

sudo service binfmt-support start

And now we can do:

> fun@DESKTOP-7F6DU8P:~$ wine --version

> wine-3.0 (Ubuntu 3.0-1ubuntu1)

Encarta 97 doesn't install, though:

> fun@DESKTOP-7F6DU8P:/mnt/e$ wine SETUP.EXE

> wine: Unhandled page fault on read access to 0xffffffff at address 0x11df:0x00002c11 (thread 0011), starting debugger...

> 0011:err:seh:start_debugger Couldn't start debugger ("winedbg --auto 15 108") (2)

> Read the Wine Developers Guide on how to set up winedbg or another debugger

I'll leave that bit to someone who knows what they're doing.

oh, and Encarta 97 works flawlessly in Wine 4.13 on Linux

and continues to fail in Wine 4.13 on Windows 10 with qemu doing the win32 bits

So, like any good geek solution, it doesn't actually solve the user's original problem at all.

Brilliant!

There are some older apps that just work on WINE and little else. I have an old Garmin GPS simulator used in some of the planes I fly. Would run on XP64, but Window 7+ could not mimic the settings well enough to get it to work even with the compatibility mode set. Ironically, this old bit of software still runs on my Linux box as it does something legacy correctly.

Too bad Microsoft chose to name their solution "WSL". If they'd have named it Line (Line Is Not an Emulator or LINux Emulator) then we could have called this Wine onLine!

+1 for LINE as in Line Is Not (an) Emulator

The original was called SFU. https://en.wikipedia.org/wiki/Windows_Services_for_UNIX

Too bad they didnt call it Windows Services Toolkit for Unix.

It's a shame WSL will be replaced soon with WSL2, which is a mere virtual machine and not native support for Linux binaries.

LTSC 2019 contains the WSL and is supported until January 9, 2029

Isn't that short for "Windows 10 Enterprise LTSC 2019"?

Am curious how an individual would get access to Windows 10 Enterprise.

One easy way is to sign up for MSDN.

I think that only gives you the 90-day trial versions, no?

If you're not averse to "sailing the high seas", so to speak, the ISOs are readily available online and don't require activation to be fully usable (as long as you're able to tolerate the Windows activation nag watermark and the lack of theme personalization, though I'm sure there are ways to "fix" both of those).

I'm guessing they will keep WSL1 around for backwards compatibility for some time, currently you can convert installations between WSL1 and WSL2.

> We currently have no plans to deprecate WSL 1. You can run WSL 1 and WSL 2 distros side by side, and can upgrade and downgrade any distro at any time.

https://docs.microsoft.com/en-us/windows/wsl/wsl2-faq

I find it unlikely MS will keep it definitely, and with no continued development effort it will become less compatible with new Linux distros, and thus diminish in utility over time.

Correct me if I'm wrong, but this is running Wine on Linux on Windows. Not running Wine on Windows.

When people say 'Linux' in reference to WSL1, it's a Linux Kernel API emulation layer on top of the Windows kernel that ships with Windows. The user-mode stuff on top of that is regular Ubuntu or whatever, but you can argue that Wine is running on Windows, it's just speaking the Linux system call language and using some user-space linux libraries instead of win32 libraries.

So I guess WSL1 is a bit like linux flavoured wine :-)

> When people say 'Linux' in reference to WSL1, it's a Linux Kernel API emulation layer on top of the Windows kernel

I have always thought it was some kind of "low level" VM. Based on your comment, it's more like a Frankenstein monster...

The Windows kernel is a true micro-kernel, unlike the monolith of Linux, and the Frankenstein mess of Mac "OS". Different API subsystems can run on top of it. There used to be a supported POSIX subsystem.

Since when is Windows a true microkernel? NT 3.51 was a bit micro-ish, but newer versions are mostly monolithic.

No, WSL 1 was an actual kernel layer. WSL 2 actually is a real Linux kernel on top of a VM but with some extra bits to integrate nicely with the Windows side of things.

> Correct me if I'm wrong, but this is running Wine on Linux on Windows. Not running Wine on Windows.

Technically speaking Wine is running on a emulated Linux-kernel (WSL1), just like Windows-programs under Wine is running on an emulated Windows-kernel.

So yeah. Turtles all the way down.

Already done[0] natively - dgvoodoo. Great performance and compatibility, turns Glide, directdraw, DX7-9 to DX11.

[0] http://dege.freeweb.hu It's an http-only website, don't be alarmed by warnings.

The funniest thing would be Microsoft hiring Wine developers to make programs written for old Windows run on newer versions of it.

No, the funniest thing would Microsoft making Windows 11 a Linux distro with a custom version of WINE running ontop of it so that they need to maintain way fewer parts of their operating system themselves.

No, the funniest thing would be Microsoft open sourcing Windows 10 and replacing Linux by a kernel-mode compatible WSL 3.

anticipated in 2005 https://www.wired.com/2005/02/microsoft-5/

This would be awesome...I have a bunch of old games that broke when I went to 64-bit Windows. Plus, VMware support for older OSes seems to be getting worse, so that's a less and less viable route.

Have you not tried VirtualBox instead? Never really had many issues with VB. Course it depends on what games too. Windows 10 does have compatability mode as well which can be useful.

I always try VirtualBox if VMware doesn't work. Sometimes that does the trick.

WSL2 is in beta now if anyone on HN feels like getting 32 bit apps to work.

Am I correct in thinking WSL2 needs Hyper-V to be enabled?

What's the advantage of it versus running Ubuntu in a VM and using putty?

It's only virtualising the kernel - not the entire OS, so in theory performance should be a lot better.

This right here. Plus you can virtualize multiple distros and not eat up all your RAM.

From the comments, WSL2 is not needed:

The procedure to use 32-bit under WSL-1 is the following:

    enable i386 architecture
    install multilibs
    install qemu-user-static

    $ sudo update-binfmts --install i386 /usr/bin/qemu-i386-static --magic '\x7fELF\x01\x01\x01\x03\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00' --mask '\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xf8\xff\xff\xff\xff\xff\xff\xff'

reload binfmt:

    $ sudo service binfmt-support start

and it executes x86 elf on WSL

More info on this technique here: https://stackoverflow.com/questions/42120938/exec-format-err...

I wish I could play the old spider solitaire, not the new one. The new one is not free and has micro transactions. That's pretty sad. I'm sure it's not even possible to find the old exe. There are js equivalent but none are really worth it.

PySol is a free download with spider and about 1,000 other solitaires, including mahjong. My only complaint is the tilesets could be a bit clearer conveying height for mahjong. Surprisingly small too.

https://pysolfc.sourceforge.io

Microsoft is known for its outstanding backward compatibility. Will Wine take over that role?

I think Wine is what solidified this belief even further when we see some elaborate Wine configs out there going on about specific versions of Wine working best with specific programs. The backwards compatibility of Windows is unrivaled at least with Wine. Not sure if ReactOS is a solid exception.

So with this I think we need to set the bar higher. How does this sound: running Mac on Linux on Windows on a Mac?

Paraphrasing doctor Malcolm: "Your software developers were so preoccupied on whether they could, they didn't stop and ask if they should"

This made me laugh out loud. Sooooo true.

"The excuse is 'what about ancient applications that don't run properly in recent Windows.' But you know the real reason is 'I suffered for my art, now it's your turn.'"

Windows kernels all the way down.

we need to go deeper ...

I'm searching for a short TL;DR for the question: WHY?

Why should anyone do that? The only reason I see is possibly to use win 98, 2000, XP, ... programs under win 10.

Yep. The easiest way to get some older games working on Windows 10 is already to copy the Wine version of DLL files they rely on into the game directory; this just goes all the way.

I don't know what this achieves over booting up a VM of an old OS to run your programs.

WSL is VM. So it's pretty pointless to run application on Linux VM emulating WinAPI, indeed. But at least you don't need to care about licenses, that might be one reason.

WSL is not a VM. The upcoming WSL2 might be, though.

I'm pretty sure WSL2 is going to use a user mode kernel

IIRC the NT kernel can run multiple kernels-or-something side by side. It could probably be used to co-run Linux kind of like CoLinux does.

IIRC also, MS can use the Windows HyperV infrastructure to run the Linux kernel too, like they do on Xbox One to segregate games "Exclusive" OS from apps "Shared" OS. In that sense it won't be user mode either like user-mode linux is.

My bet is on the latter.

https://en.wikipedia.org/wiki/Architecture_of_Windows_NT

https://en.wikipedia.org/wiki/Xbox_One_system_software

https://en.wikipedia.org/wiki/Cooperative_Linux

https://en.wikipedia.org/wiki/User-mode_Linux

Well I'll be damned, someone knows about CoLinux.

The WSL2 install command is ( https://docs.microsoft.com/en-us/windows/wsl/wsl2-install )

    Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform

which suggests it's a virtual machine.

WSL2 is already available in the Windows Insiders Fast Ring. It is, indeed, a VM running on top of HyperV.

WSL is not a VM.

First and foremost, security. Also convenience - no need to mess around with shared folders, NAT-based VM networking, OS updates, user accounts/passwords etc.

Anyone who is using that old of software through a VM to conduct business is wasting more money maintaining that setup than if they migrated somehow.

I don't believe this is a good business strategy.

It's not just for business, it's also relevant for old games fans - and will become ever more important for those of us who refuse to buy the "new" games that require a whole ssd for space, are plagued with drm and bugs and to top it off are pay2win upon paying 40€+.

But for those games you don't really need to setup the works of a business layout. Just keep your stuff within the VM no need to share folders.

Reply on news.ycombinator.com