Slashdot Mirror

I did rent a Tesla and my real range was about 50% of its EPA range. Kona has EPA range 485km. If it behaves in high speed driving (175km/h) and winter conditions (around 0'C) the same as Tesla Model S (does it?) then its real winter fast drive range is about 242km. Therefore to drive to a city and back the city must be at most 121km away. The capital is for me 122km away, that is too tight for practical usage. Yes, I can drive slower but then it is often even colder than 0'C, one needs to drive some errands in the capital, one should keep at least 10% battery reserve (that is 109km range) etc. A bit more range of Tesla would satisfy me (but not so its price).

I do not know where to put the printks off the top of my head as I am not a kernel developer. I provide similar debugging services for GDB where I know the codebase thoroughly. I could read+learn the kernel sources to find out where to put the printks but that does not scale, life is too short to know very every line of system sources, that is what developers specialization is there for.

The problem happens due to my scripts running nightly regression testing of various toolchain components in various (chrooted) operating system variants/versions. Currently I "do not do that" as you suggest because of that bug. Therefore users hit+bugreport those regressions. Formerly I was fixing the regressions before any user could hit them, that was a so-called proactive solution. Yes, I could code the scripts some other way (such as using KVM instead of chroot) but that would be a workaround, the scripts are not buggy, the kernel is. I can provide the scripts but there are many of them and setting up the whole system for them is not easy, it was done ad hoc: 1 2 3 4

I do not know where to put the printks off the top of my head as I am not a kernel developer. I provide similar debugging services for GDB where I know the codebase thoroughly. I could read+learn the kernel sources to find out where to put the printks but that does not scale, life is too short to know very every line of system sources, that is what developers specialization is there for.

The problem happens due to my scripts running nightly regression testing of various toolchain components in various (chrooted) operating system variants/versions. Currently I "do not do that" as you suggest because of that bug. Therefore users hit+bugreport those regressions. Formerly I was fixing the regressions before any user could hit them, that was a so-called proactive solution. Yes, I could code the scripts some other way (such as using KVM instead of chroot) but that would be a workaround, the scripts are not buggy, the kernel is. I can provide the scripts but there are many of them and setting up the whole system for them is not easy, it was done ad hoc: 1 2 3 4

I do not know where to put the printks off the top of my head as I am not a kernel developer. I provide similar debugging services for GDB where I know the codebase thoroughly. I could read+learn the kernel sources to find out where to put the printks but that does not scale, life is too short to know very every line of system sources, that is what developers specialization is there for.

The problem happens due to my scripts running nightly regression testing of various toolchain components in various (chrooted) operating system variants/versions. Currently I "do not do that" as you suggest because of that bug. Therefore users hit+bugreport those regressions. Formerly I was fixing the regressions before any user could hit them, that was a so-called proactive solution. Yes, I could code the scripts some other way (such as using KVM instead of chroot) but that would be a workaround, the scripts are not buggy, the kernel is. I can provide the scripts but there are many of them and setting up the whole system for them is not easy, it was done ad hoc: 1 2 3 4

I do not know where to put the printks off the top of my head as I am not a kernel developer. I provide similar debugging services for GDB where I know the codebase thoroughly. I could read+learn the kernel sources to find out where to put the printks but that does not scale, life is too short to know very every line of system sources, that is what developers specialization is there for.

The problem happens due to my scripts running nightly regression testing of various toolchain components in various (chrooted) operating system variants/versions. Currently I "do not do that" as you suggest because of that bug. Therefore users hit+bugreport those regressions. Formerly I was fixing the regressions before any user could hit them, that was a so-called proactive solution. Yes, I could code the scripts some other way (such as using KVM instead of chroot) but that would be a workaround, the scripts are not buggy, the kernel is. I can provide the scripts but there are many of them and setting up the whole system for them is not easy, it was done ad hoc: 1 2 3 4

Using $HOME in CVS since 2001, it works perfectly, it is public:
cvs -d :pserver:pserver:@dyn.jankratochvil.net/cvs co nethome
Checking it out across the world on various machines. If I find I miss something on some host, I do `cvs update' by hand. Not a rocket science.
I have only one host I consider secure enough so there is no point in distributed mails.
I was using my Gecko bookmarks in $HOME but I had to create a small script to "normalize" them. Otherwise they contain a lot of useless info (timestamps, whether expanded etc.) making both history diffs useless and conflict merges difficult/impossible.

Not long after the first requests for proxies went out, went out the requests for "So how do I configure this again?".

So I created ProxyBox [mirror] to help people get stuff setup quickly. It has squid (listening on a multitude of ports), tor, & ziproxy. It was quick and dirty (and the file size shows). Not to mention I'm just a Mechanical Engineer, not a security expert. This was meant for the fark crowd and not for the slashdot, I'm sure everyone here is more than capable of setting up some proxies.

Austin Heap has been distributing the Proxies to Iranians on the inside via twitter and such. (Twitter) his biggest problem right now is ssh servers inside of Iran to make sure that proxies work. Supposedly he's also been able to set up VPNs on fast connections. But work is slow because the internet is slow and he's down to 1-2 SSH boxes ATM.

They've already started blocking ports 80,81, 3128 & 8080. And starting to send fake RESETs on TCP connections (Comcast anyone?).

How you can help:
Well I'd like some help making ProxyBox a ton smaller. If DSL can get a full GUI in 50MB, there's no reason ProxyBox should be 400MB. I'd also like to turn it into a LiveCD or LiveUSB so it can be set up by anyone not just with VirtualBox. (jjarvis98 at gmail.com)

Tor is being used quite extensively. Some people have setup exit nodes and had their connections filled with people hitting nothing more than twitter, facebook & youtube. Set up an exit node or bridge if nothing else.

Supposedly UDP and ping still work fine. So some people are looking into TCP over UDP or I was also thinking about Ping Tunnel (Tcp over Ping)

#irantech on irc.freenode.net is a bit unorganized but it's working for now.

Does this mean someones finally going to get NTFS working in linux?

I really hope this means it's time for some proper write support to NTFS

Have you tried Captive NTFS?

> Pretty laughable.

Quite.

> They still havn't got full NTFS support in Linux yet.

Oh really?

> Perhaps they should concentrate on their 1st....

Their first is supporting Microsoft's broken proprietory technology? Who knew.

NTFS support in linux is not safe as far as I'm aware. All of the NTFS mounting tools I've tried have recommended mounting read-only unless you really have to.

You really should take a look at the current status of the NTFS drivers. They are now quite safe (although a backup is always something you should have anyway).

The kernel driver was completely rewritten in 2002 (the version prior to the rewrite was NOT safe). It has all the read-related features you would expect; write support is limited, and it will only do things it knows it can - other operations are refused. You can also use a userspace version of the driver (albeit with a performance penalty) and the "ntfsprogs" to get more write functionality. Again, it's safe - if an operation is not safely doable, it is refused. See Linux NTFS driver for details.

There are alternatives too: there is Jan Kratchovil's Captive NTFS driver, which uses the Windows ntfs.sys driver. This can do everything (of course), but is a user-space driver, which means it's not that fast; I'm not sure how stable this is either.

You can also buy Paragon Software's commercial NTFS driver for Linux. Do not confuse this link with the linux-ntfs one! They have a demo version you can download, and it also provides full read-write access.

If you know of a Windows ext3 or Raiser driver, then please tell me.

If you want to read/write ext2 and ext3 under Windows, try this driver. I've been using it (over Firewire and USB). It works well and transparently. You should use the hack of changing the partition type to "NTFS" with cfdisk on external drives so that the Windows PnP notification works for hotplugging; the partition itself stays formatted with ext2/3 (both Windows and Linux look at partition content instead of the partition table to determine the format when mounting). This is mentioned in the included documentation; the alternative is a control panel to assign letters to ext2/3 partitions. You don't need to reboot after installation before the driver can be used; you still need to use Linux to mkfs and fsck any ext2/3 paritions though.

-- Steve

Captive does a suitable job of reading/writing NTFS partitions. you do need 2 NTFS driver files from Windows tho, so if you're a license purist then it's not the solution for you.

At first I thought it was a sequel to some game, then I read the article and realized it was a Linux OS distribution. Somebody call me when Linux will install onto a NTFS partition and read the transparently compressed files, share it with Windows, and not need any other partitions, like one for the Swapfile. It can use http://www.jankratochvil.net/project/captive/ for all I care.

Are we unaware of Captive NTFS?

Good MSN with all smileys, filetransfer, videochat.
I think these people must have missed Kopete.
Using a nifty script you can download the official icons from the MSN server and use them without a problem. It has had file transfer support for ages now, and has acquired webcam support quite recently.

Support for all streaming media in your webbrowser.
Mplayer-plugin is a Mozilla/Firefox plugin that lets you display Windows Media, QuickTime, MPEG, Ogg Vorbis, and Real format movie clips in your web browser. Works perfectly for me.

Oh yeah, for the transition, full NTFS writing support.
Moving from NTFS to ext3 or Reiser shouldn't require NTFS write support, should it? With that said, Captive has been providing this for a while.. never used it myself, but I hear good things about it.

Happy?

You could try Captive NTFS.

You use this nifty registry editing boot disk to fix the registry

And you use the linux NTFS tools and TestDisk to undelete/unformat/rebuild lost or damaged files and partitions. I use these all the time, they work REALLY well.

I carry around a copy of Damn Small Linux on my USB key, customized with above tools and including an image of the registry editing floppy and endless other utilities. Not to mention, DSL Linux gives me full access to the Debian APT repository! It serves me very well, especially since it can boot entirely into RAM, so I can take my key out and boot additional system.

Captive NTFS has worked fine for me. I keep the couple of XP files I need on a USB key, and together with a Knoppix CD, I haven't had any problems so far.

I would be very suprised if this distro can write to NTFS safely as this is something that is still being worked on.

Is it still being worked on? I'm still confused. I thought it was too, then I found this.

http://www.jankratochvil.net/project/captive/

Linux has been able to read NTFS partitions for a long time, there has been experimental NTFS writing, which has been largely considered harmfull and AFAIK a rewrite is on its way. In the mean time something very cool is included in Knoppix: Captive NTFS. This is a technique where the original ntfs.sys driver from windows is borrowed, either from your windows partition or by downloading a service pack from windowsupdate.microsoft.com and pulling the drivers from there. I have used it and it has worked fine, EXCEPT on realy large files. Like avi files of 600Mb+. The thing is, even those failed operations (the computer slowed to a crawl) didn't damage my NTFS filesystems.

I haven't DL:ed the last versions of Knoppix but as late as in 3.7 Captive NTFS was included. It's higly improbable that is has been excluded. Anyway, even if it has been removed you can still read your NTFS partition.

Cheers...

Captive NTFS should allow you to write to NTFS by loading the Windows binary driver. It's probably part of some rescue discs (there were plans to add it to Knoppix).

Despite the unforutnate name, WinFS is a service that runs above the filesystem. The data is still stored on a plain old NTFS partition(s).

For traditional file-based data, such as text documents, audio tracks, and video clips, WinFS is the new Windows file system. Typically, you will store the main data of a file, the file stream, as a file on an NTFS volume. However, whenever you call an API that changes or adds items with NTFS file stream parts, WinFS extracts the metadata from the stream and adds the metadata to the WinFS store.

source: Microsoft's WinFS developer page

The data is still just as (in)accessible as it's always been. The meta data is locked away in the WinFS store but we haven't been using that all this time so it's not like we're going to be any worse off.

as for writting NTFS, I suggest you take a look at captive NTFS which lets you read and write your NTFS partitions in Linux with the same confidence that you do in Windows.

Knoppix uses the rewritten NTFS driver which supports loopback read-write mounting a file on NTFS. Nothing new, the now also dead Phat Linux already did the same in 2002 with the same open source kernel driver. Currently the most popular "run Linux from NTFS" distribution is TopologiLinux.

It's very nice to see Knoppix caught up too.

As the summary hints at writing to NTFS, will this version of Knoppix use Captive NTFS in some manner, or is it just going to write to a loopback file to get around the problems with using the native Linux driver for writing to NTFS?

http://ndiswrapper.sourceforge.net/

Some vendors do not release specifications of the hardware or provide a linux driver for their wireless network cards. This project provides a linux kernel module that loads and runs Ndis (Windows network driver API) drivers supplied by the vendors.

http://www.jankratochvil.net/project/captive/

Project implements the first full read/write free access to NTFS disk drives. You can mount your Microsoft Windows NT, 200x or XP partition as a transparently accessible volume for your GNU/Linux.

This compatibility was achieved in the Wine way by using the original Microsoft Windows ntfs.sys driver. It emulates the required subsystems of the Microsoft Windows kernel by reusing one of the original ntoskrnl.exe, ReactOS parts, or this project's own reimplementations, on a case by case basis. Project includes the first open source MS-Windows kernel API for Free operating systems. Involvement of the original driver files was chosen to achieve the best and unprecedented filesystem compatibility and safety.

(you can use the FUSE LUFS wrapper to run this, as LUFS is now unmaintained).

Linux can write NTFS, but uses MS files to do so. Tried it a few months ago but couldn't get it to work (on a Knoppix live CD anyway), but no idea how far it has came since then.

I wouldn't use NTFS anyway. It is too easily corrupted (especially by MSW XP) and not easily recoverable.

Captive RW ntfs. Absolutely brilliant. And, as long as you mount your ntfs partition first using your distribution of choice's read-only ntfs driver, installation is a snip.

I must admin that in this case Microsoft behave as well as it could, no known faults on its side. I had to retrieve the mails and I really remembered it exactly the way I wrote it (wrongly) in my original comment.

The mail regarding the compatibility: mbox.

My apologies _for_this_specific_case_only_ to Microsoft.

D3D relies heavily on a lot of the rest of the Win32 API ... you might as well have said, "why doesn't somebody just port Windows to Linux so we can forget about all this bullshit?"

Replace "Linux" with "an open-source version". The question then simplifies to "Why doesn't someone either port DirectX or add support for Microsoft's downloadable DirectX to ReactOS, which is working towards a Win32 API anyway?"

Speaking of MS's own DirectX implementation, can't that be run under Linux in a Captive-like manner? It ought to simplify porting if developers know they can use the same DirectX DLLs under Linux.

The is the consequence.

The cause is the missing LSB (Linux Standard Base) or whatever to be able to release tool working on all GNU/Linux distros.

I was trying hard, I had to patch 12 packages to be able to build the package fully statically at all.

Still it is incompatible on the any other than those 5 tested distros.

If you have a copy of an NT based OS, you can use captive to get read/write access to your NTFS filesystems.

There is a way to get read/write support for NTFS now. It uses the real NTFS.SYS driver. Here it is: Captive

One of my custom Knoppix discs had the Captive NTFS project installed with it. I've used it quite a few times without a problem.
It's available here: http://www.jankratochvil.net/project/captive/

That's the only "safe" way to write. There's some expirimental code that's almost guaranteed to fubar the whole filesystem if you use it to much.

Thats just the kernel filesystem driver, though, you can access NTFS via window's own NTFS.SYS driver.

Apparently it can be done. Take a look at this.

http://www.jankratochvil.net/project/captive/

This compatibility was achieved in the Wine way by using the original Microsoft Windows ntfs.sys driver. It emulates the required subsystems of the Microsoft Windows kernel by reusing one of the original ntoskrnl.exe, ReactOS parts, or this project's own reimplementations, on a case by case basis. Project includes the first open source MS-Windows kernel API for Free operating systems. Involvement of the original driver files was chosen to achieve the best and unprecedented filesystem compatibility and safety.

agreed, there is absolutely no way to run ntfs under linux ...

when the fs type is antiquated and unused, of course!

However, note that you already can alter files, assuming that the size doesn't change. No harm comes from setting a 0 to a 1 in an ini file with the kernel's ntfs driver.

There's also 3rd party drivers that use an emulation layer and windows' ntfs.sys to give full and safe rw access.

The Captive project

Do note, however, that there's plenty of other ways to transfer files on a dual-booting machine. I probably do more writes to my 30gb fat32 partition (out of 320 total) than I do any other partition on my triple booting rig, here. Also, there's win32 tools that'll read from ext2 and reiserfs partitions. ext3 doesn't seem to work, although that might be a partition size matter, not a partition type one. I have a 110gb partition that the win32 explore2fs tool can only read about half of.

The captive is not the vanilla kernel ntfs driver, it's a method of using wine to emulate necessary parts of winnt kernel, allowing use of the original ntfs.sys drivers to enable full read/write. Obviously this requires you to have windows, but then again if you don't, ntfs is probably not a problem.

Not unlike the original hacks to enable viewing of windows media, quicktime and realvideo/audio using the win32 dll's.

Thanks! Here's my list. The stuff I carry is usually for cases where I can't access the network or hardware. If the machine sees the network, I've got it made.

I mentioned these two, but here are details.

chntpw, reset NT/2k/XP passwords with the full bootable floppy version.

Bart's network boot disk built into a 2.88 meg image allows a huge load of network drivers, and with a copy of ghost I don't ever have to mess with building boot floppies for ghost again. I also included basic DOS utilities for manipulating the HDD and testing.

Bootable CDs with floppy images can be useful, and Bart provides a handy utility for building them. Put a disk image of chntpw on a bootable CD with other goodies per instructions at Bart's site.

I also carry Knoppix or perhaps a nice Bootable Business Card with lots of network drivers. With read-only NTFS access and networking, I've stripped data off of drives I couldn't even access for a fresh NT/2k install. Pour it across the network, and you're a hero. Also good for a slow clone with dd, or an emergency Remote Desktop Client. If you pick a livecd with a nice recent version of kparted, you can resize live NTFS partitions (I used SystemRescueCD). I've needed to do this more often than I'd have expected. Knoppix's NTFS tools were less useful at the time.



I'm looking forward to using the Captive NTFS drivers, but that seems less neccessary with one more set of tools from Bart's site, the bootable XP/2000 pre-execution environment in BartPE. These allow full access to NTFS, as well as providing an environment you can run Adaware and other Windows tools from. One of these made my day last week. It's dog slow to boot, but running Adaware or other utils (chkdsk, AV, undelete), from NOT the boot drive is great.

Ok, a little offtopic, but can't driver problems like this be fixed by using a wrapper with the dlls like Captive? I know that you have to have the original DLL files (download/copy them yourself), and it won't be in the "true spirit" of open source software, but like me, most people just want their stuff to work. And if it's preventing you from something like getting your computer onto a network, why the Hell not?

Since it can't re-ship Windows binaries, it does a really neat trick of going to Microsoft's site and pulling out of the 30 MB (or so) XP SP1 installer, exactly the bytes it needs for the files it requires (something like 3 MB). Of course Microsoft could post a different installer, or change the URL, but for now it works and works very well.

I want to create a custom data recovery, virus scanning and hopefully spyware detection CD using SystemRescueCd and Sophos AV for Linux. The only thing missing in this equation is anti-spyware software that runs on Linux but scans Win2k/XP partitions. My alternative to this solution is using a DOS boot disk then use something like Winternals NTFSDOS Pro and finally run Sophos AV for DOS - which would still not give me an anti-spyware tool unless the host OS is used. The Linux CD would make use of the Captive project to access the NTFS partitions with R/W capabilities. Obviously I would prefer using the Linux solution, I guess I could scan for viruses first and then boot into Windows to run Ad-Aware but I'm curious if there's an opensource or commercial project that deals with this on Linux.

The Captive is working very nice for me, thoug a bit cpu intensive and slow but otherwise working perfect for my Mandrake 9.2 and the install was easy. here is the discription from the website:

"Project implements the first full read/write free access to NTFS disk drives. You can mount your Microsoft Windows NT, 200x or XP partition as a transparently accessible volume for your GNU/Linux.

This compatibility was achieved in the Wine way by using the original Microsoft Windows ntfs.sys driver. It emulates the required subsystems of the Microsoft Windows kernel by reusing one of the original ntoskrnl.exe, ReactOS parts, or this project's own reimplementations, on a case by case basis. Project includes the first open source MS-Windows kernel API for Free operating systems. Involvement of the original driver files was chosen to achieve the best and unprecedented filesystem compatibility and safety."

This boils down to two options for the user:

• 1. Slow but perfect R/W acces with Captive.
• 2. Fast read(almost)only acces with the buildin NTFS-driver in the 2.6.x kernel.

The Captive is working very nice for me, thoug a bit cpu intensive and slow but otherwise working perfect for my Mandrake 9.2 and the install was easy. here is the discription from the website:

"Project implements the first full read/write free access to NTFS disk drives. You can mount your Microsoft Windows NT, 200x or XP partition as a transparently accessible volume for your GNU/Linux.

This compatibility was achieved in the Wine way by using the original Microsoft Windows ntfs.sys driver. It emulates the required subsystems of the Microsoft Windows kernel by reusing one of the original ntoskrnl.exe, ReactOS parts, or this project's own reimplementations, on a case by case basis. Project includes the first open source MS-Windows kernel API for Free operating systems. Involvement of the original driver files was chosen to achieve the best and unprecedented filesystem compatibility and safety."

This boils down to two options for the user:

• 1. Slow but perfect R/W acces with Captive.
• 2. Fast read(almost)only acces with the buildin NTFS-driver in the 2.6.x kernel.

Last time i checked, the NTFS write support was not mature enough to be used fulltime. Has anyone used this? Is the write support completely reliable?

I couldn't say for sure how Mandrake is doing it, but there is fully functional ntfs read/write support out there: Captive NTFS

This sounds as useful as using a Windows .dll file in Linux-- it's not.

Wrongo. Windows DLLs have been highly useful to x86 Linux users in many situations.

If you want to write a Windows-formatted drive from Linux, for example, the safest way is to load the Windows ntfs.sys driver into Linux. (There's also native Linux NTFS support, but it's still not 100% reliable for writing to the disk)

Also, if you'd like to watch a video formatted in Microsoft ASF/WMV or Quicktime MOV, then installing a Windows DLL is your best bet (maybe only bet?). I certainly know that trailers.apple.com would be useless to my Linux system without several critical DLLs.

(Note that non-Intel-compatible Linux systems still cannot use DLLs reliably, as that would need CPU emulation as well)

Skilled OS developers have been able to achieve binary compatiblity with programs and libraries from other platforms for many years.

• Examples are ndis and ntfs.sys. This trend will continue.

Does Captive NTFS (ntfs.sys) work for you? Users report very slow speed (50-100 KB/sec) and lost data. Even the author cannot promise any" reliability.

• Examples are ndis and ntfs.sys. This trend will continue.

Does Captive NTFS (ntfs.sys) work for you? Users report very slow speed (50-100 KB/sec) and lost data. Even the author cannot promise any" reliability.

There already is full NTFS read/write support on Linux. http://www.jankratochvil.net/project/captive/ allows full and safe read/write of NTFS drives/partitions.