Slashdot Mirror

No, cgroups & co are there and functional. Namespacing, what I think you really meant, is not yet globally enabled, so no containers.

Namespacing is what I meant by "& co" - i.e.: and all the other kernel bits that make container isolation possible but written shorter.

Yes, this is because as a guest,

No, it's not a "guest". There's no virtualization going on, it's not Hyper-V based.
It's supposed to be just a different set of API made available by the NT kernel, in addition to win32.
The same way a OS/2-like API was available a long time ago.

it's not supposed to be interfacing directly with hardware, this includes block devices.

WSL's "linux-like" API is just one of the API exposed by the NT kernel.

in Win32 API mode, the kernel *does* expose to application some hardware including block devices (used by several user-space utilities. Including disk-image writers, and including user-mode tools to access Ext2/3,ReiserFS, etc.)

in WSL mode, ELF are just regular applications running on top of the kernel. But they don't get access to block devices.
Neither in kernel-mode (forget about installing a linux filesystem driver)
nor in user-mode (no FUSE for you).

They don't get access to USB (libusb works on Linux, work in Win32, but not in WSL).
They don't get access to tons of things.

(We could add : no DRM gfx stack, you're limited to X forwarding over SSH, so no wayland compositing either)

Again..... hardware.

Well okay, I was excessively condesning this one (the normal path is DRM(kernel API) -> DRI(user-land component) -> Mesa(OpenGL and co) -> Wayland)
But, compositing is *entirely* user-space on Linux.

It requires OpenGL, and a few extensions.
(NVidia wasn't providing them, until recently, when they started providing a different set than anyone else, forcing Wayland to feature different paths depending on the hardware.)

It's a normal userland library, whose call are availble to Win32 application (say, Quake3), but not in WSL.
Same goes for Vulkan.

Android userspace requires, among direct hardware access, non-mainline kernel extensions....

Android userspace is the whole reason Microsoft started the thing that is WSL now.
- Direct hardware access : not in any way more than what any other Windows application would ask access for.
- And whether Binder IPC is part of the mainline kernel or not has absolutely nothing to do with WSL. WSL does not use any bit of the Linus kernel. It just tries to expose the same API to applications. Binder IPC not being present in upstream vanilla kernel has nothing to do with microsoft not providing the API in WSL.

You have a very strong opinion about something that you apparently have very little knowledge about.

I've been successfully using WSL to run scientific computing software on Windows.
I've been following the various blog post of Microsoft on the subject.
I might have a tiny bit more experience and knowledge than you presume.

I'm just point out that currently WSL is just basically some high-level file I/O and some network socket binding and that's about it.

Which covers lots of devs' use-case, and end-user simple use-case (As said above, it worked for us). But that's about it.

No, cgroups & co are there and functional. Namespacing, what I think you really meant, is not yet globally enabled, so no containers.

Namespacing is what I meant by "& co" - i.e.: and all the other kernel bits that make container isolation possible but written shorter.

Yes, this is because as a guest,

No, it's not a "guest". There's no virtualization going on, it's not Hyper-V based.
It's supposed to be just a different set of API made available by the NT kernel, in addition to win32.
The same way a OS/2-like API was available a long time ago.

it's not supposed to be interfacing directly with hardware, this includes block devices.

WSL's "linux-like" API is just one of the API exposed by the NT kernel.

in Win32 API mode, the kernel *does* expose to application some hardware including block devices (used by several user-space utilities. Including disk-image writers, and including user-mode tools to access Ext2/3,ReiserFS, etc.)

in WSL mode, ELF are just regular applications running on top of the kernel. But they don't get access to block devices.
Neither in kernel-mode (forget about installing a linux filesystem driver)
nor in user-mode (no FUSE for you).

They don't get access to USB (libusb works on Linux, work in Win32, but not in WSL).
They don't get access to tons of things.

(We could add : no DRM gfx stack, you're limited to X forwarding over SSH, so no wayland compositing either)

Again..... hardware.

Well okay, I was excessively condesning this one (the normal path is DRM(kernel API) -> DRI(user-land component) -> Mesa(OpenGL and co) -> Wayland)
But, compositing is *entirely* user-space on Linux.

It requires OpenGL, and a few extensions.
(NVidia wasn't providing them, until recently, when they started providing a different set than anyone else, forcing Wayland to feature different paths depending on the hardware.)

It's a normal userland library, whose call are availble to Win32 application (say, Quake3), but not in WSL.
Same goes for Vulkan.

Android userspace requires, among direct hardware access, non-mainline kernel extensions....

Android userspace is the whole reason Microsoft started the thing that is WSL now.
- Direct hardware access : not in any way more than what any other Windows application would ask access for.
- And whether Binder IPC is part of the mainline kernel or not has absolutely nothing to do with WSL. WSL does not use any bit of the Linus kernel. It just tries to expose the same API to applications. Binder IPC not being present in upstream vanilla kernel has nothing to do with microsoft not providing the API in WSL.

You have a very strong opinion about something that you apparently have very little knowledge about.

I've been successfully using WSL to run scientific computing software on Windows.
I've been following the various blog post of Microsoft on the subject.
I might have a tiny bit more experience and knowledge than you presume.

I'm just point out that currently WSL is just basically some high-level file I/O and some network socket binding and that's about it.

Which covers lots of devs' use-case, and end-user simple use-case (As said above, it worked for us). But that's about it.

http://www.chrysocome.net/dd

Simple in windows too.

The simplest way is to get an image that you just copy over the main partition of the drive.

"dd" works for that on the command line of Linux
"rawwrite" is a nice Windows GUI

Then there are USB boot-disk maker.
e.g.: there's Unetbootin which downloads an installation ISO and handles the gory details to create a bootable USB stick out of it.
(And for the curious there's a tool for the opposite direction: making a bootable Windows out of an Microsoft's installation ISO).

The gory details:
There are basically 2 different ways to boot a media.

old-school classic BIOS:
- requires a special master-boot record at the beginning of the disk, which in turn will load a boot loader (e.g.: syslinux or grub or lilo) from a specific place (usually hidden between partitions), which then will handle the necessary boot menu and boot linux.
By writing a whole boot-USB image ("dd" method) these extra parts are written too.
And tools like Unetbootin take care of running the necessary soft for it.

new style UEFI:
- the UEFI is able to handle a lot of its own (access to partitions on disks).
- it requires an executable file (.efi) placed in a specific partition (the first FAT32 partition, usually called the "System partition") in a specific path. The UEFI takes care of loading and executing this file (usually, it's going to be grub2.efi) which then will handle the necesary boot menu and boot linux.
That's usually the intended methode behind all the ultra-simple "just copy the files as-is on the USB stick, lol" HOWTOs.
Images copied with the DD mathod will already be formated in the correct formats and partitions.
Unetbootin will re-format and repartition the USB stick if necessary.

Things can get problematic, if:
- ...the target PC boots in BIOS mode and the proper sectors (Masterboot and bootloader) weren't written.
- ...the target PC boots in UEFI mode and the partition isn't liked (e.g.: it's an exFAT or NTFS instead of FAT32)

So, use DD, or use Unetbootin (or use WInUSB if you want to boot a Windows installer). They all handle the gory details.

http://www.chrysocome.net/dd

You're welcome.

If you don't want much hassle, just use explore2fs (http://www.chrysocome.net/explore2fs). It's an userland application which does not install any drivers or the like on Windows, and as such will execute as any user. However, you'll still need to transport it to the machines you'll want to use, and thus you'll need a tiny space of FAT32 for doing the trick.

If you have rights to install drivers on the windows machines you use, you can try the EXT2 driver available on www.fs-driver.org. It will mount your EXT2/EXT3 volume as a drive letter so you can transfer files between partitions.

I've never used anything other than Reiser3 with Linux. Partition resizing.

Which by it self is a sure win of Reiser3/4(*) and Ext2/3/4 versus JFS and XFS which can only increase size.
That's part of the reason I'm using it too.

Readable from within Windows via YaReG.

Another tool you might be interested by too :
Virtual Volumes.
- It's by the same guy who wrote Explore2fs
- It supports ReiserFS using the same tools (rtstools) as YaReG.
- It supports also RAID and LVM.
- Read/Write support.

And hoepfully, they'll end up adding WebDAV support so you can mount file systems under Windows.

(*): Now that development has been taken over by Edward Shishkin, shouldn't this get renamed as ShishkinFS ? :-P

There are Windows drivers for ext2 and ext3:

(i) Installable filesystem for Windows http://www.fs-driver.org/index.html

(ii) Explore2fs http://www.chrysocome.net/explore2fs

In my experience, both work very well for reading but they are not quite reliable for writing.

Actually, a version of dd compiled for Windows does exist, with pseudo devices /dev/zero and /dev/random for just this purpose. Of course, you can't do this to the system drive in Windows - it has to be unmounted first. In addition, I don't believe it supports anything beyond the partition level - So doing it to a whole hard drive may not work. I haven't really tested it to see how far it'll go, but it does work.

Still I wish windows had good support for EXT2.

Not the best, but Explore2FS is pretty nice.

Of course, writing a Windows File System is a black art. If MS documented it better, maybe there'd be more third party file systems.

You might want to look at this as well -- disclaimer, I haven't tried it, don't know how good it is.

there are several solutions to this problem.

Create a Fat32 partition and save your documents there.
or save your documents in Linux and use Explore2fs
http://www.chrysocome.net/explore2fs

I think there are better options available now, but these are the only ones I have ever used. back when I still cared about booting windows.

I see what you mean, but I guess you never heard of DVDShrink? That's as easy as clicking "backup"... A DVD copy? Coming right up!

As for dd... Let me tell you, the first Linux distro I installed was with floppy disks (remember those?) and I had to use RAWRITE.EXE under DOS to create the first boot diskette. RAWRITE.EXE is pretty much the floppy equivalent of dd for DOS. It's a command line app.... Now, it isn't anymore. Somebody could write the equivalent of "dd" for Windows with an easy interface.

All it needs to crack DRM for the greater public is one dedicated geek. It probably won't be the guy that cracked the DRM in the first place, but it will one that can use the library the first one wrote and make a halfway decent GUI for it.

Here are more notes to go with my parent comment:

Disk Image backups are required to back up the operating system drive. Disk Image backups are sector-by-sector backups. Some people call that operating system cloning or disk cloning. There is a free Linux/Unix utility called DD. DD has a Windows version, too. My understanding is that DD has no compression, so that the backups are much larger than with commercial software that compresses the images.

Microsoft has made Windows XP difficult to back up. It is necessary to have 3rd party software that can back up the operating system and also files that are in use. Windows XP will not allow copy, xcopy, or robocopy backups of the system registry for, example. For that you must have drive imaging software like Acronis TrueImage or another.

If a user forgets to close all programs, some important files may still be loaded at night and in use when backups are scheduled. That's why it is necessary to be able to back up files that are in use. Microsoft provides the API to do that, but very limited backup software called NTBackup.

Tip: Encryption is necessary. Backups that are not encrypted are somewhat useless, since it is too risky to take them off site. Remember that password protection is not encryption.

Be careful about backup software that a big company bought from some other company. When that happens, usually the technical people are fired and the company that buys the rights is not prepared technically to respect what the fired people have done. Microsoft bought rights to NTBackup from Veritas. My understanding is that Veritas bought it from Conner and Conner bought it from Arcada.

Recently Symantec bought Veritas. My experience with Symantec is that their software often has huge bugs, and their telephone support is possibly close to the worst.

I found this confused-looking but extensive list of Windows backup software: Backup Software For Windows 2000