but we already know that the OS filesystem routines have only very limited/forward compatibility/ with future NTFS versions.
Exactly. My point is, whatever forward compatibility XP NTFS has, you can be sure isn't already in the OSS NTFS. It's only stable because it's worked so far. Whatever (as yet unused) forward compat in the current NTFS is exactly the leeway immediately available. Any movement will break OSS NTFS, but not XP. In the meantime, XP can be patched with another NTFS with more goodies.
Anyway, if not factually correct, the article content is actually a good enough explanation for anybody who doesn't even know what IPv4 is, letalone what IPv6 will be.
The non-tech public don't need an understanding of a networks underlyings, and at the end of the day he probably did a better job and confused his readers less than many of us would for sure.
What about external USB/Firewire hard drives? If NTFS file systems are no longer compatible between WinXP / WinVista and Win2000, there's going to be some gnashing of teeth by end-users who use those devices
Nobody said they'd need to break compat with WinXP. You can be pretty sure the OSS NTFS driver != the WinXP driver. Changes could be made to NTFS that WinXP will survive, but the OSS driver will once again be "Dangerous" to write with. MS won't cop the blame, because it wasn't their driver that trashed it.
You can call it silly paranoia, but if I was motivated by Microsoft's profit margins, I'd do exactly the same thing, because I'm just as greedy and selfish. I'd design the FS primarly for lock-in, (implying covert changes to break compat), secondarily for integrity (because our users suck it up anyway), thirdly for speed.
The entire reason Microsoft is the most successful business in the world is that they stay compatible with more stuff for longer than anyone else.
Nonsense: NTFS is a Windows Filesystem. It's never had to be compatible with anything else, and they've clearly made no effort in letting it be. They have made changes in the past that have had consquences. (I'm not saying they made those changes to be evil, the point is, XP broke Nortons).
And who said they'd need to break XP NTFS to break Linux NTFS? I have no doubt at all the current version of NTFS is already prepared for whatever other layers of obfuscation they might add. Mark my words, NTFS was designed only to allow Windows to store and retrieve files, not you. Windows will be your vehicle for storing and retrieveing those files, they've worked damned hard at making it that way, and they'll continue to work damned hard.
and Microsoft is going to think really, really hard before they go and do something that may result in lost data.
I really must give this Widows software another try. I hear with Vista they're not only going to include security with their products, now you say they're going to thing really hard about what they do in their OS as well!
Seriously, they will think really really hard, they always have. But it's always been more in the interest of their bottom line, not mine or yours.
If they did release an update that trashed 1 or 2 % or Windows installs, they'd release another patch and the public would keep lapping it up.
I can't believe how many years it's taken to reverse NTFS. What does that tell you about a filesystem? It must be so deliberately convolted, arcane and obfuscated to have taken so much effort. The idea of storing data in blocks in a linear address space is nothing new, but somehow I don't think MS stopped when they got a working ACL-based hierachy, otherwise reverse engineering could have been done in a week.
80% of the raw material used to manufacture a PC is pure water! Water that can be recycled!
And I'm sure you're familiar with all of the processes involved in turning the water back into its pristine state we began with.
Why, they could surely just pipe the water from the factory outlet back into the factory inlet, right?
I think you might be overlooking something, son. It isn't just shite & piss we're talking about here. Hundreds of different kinds of contaminations, many involving heavy metals.
Yes, I agree completely with you about numbers and statistics, but I don't think the impact of any amount of water contamination, or the effect if it being released unpurified, is seen by you here.
Forgive me if I'm overlooking something else here but...
How about: "Don't wake on LAN?"
If it's a client machine, surely no network traffic will be interesting if the machine is unattentded. No point in waking for email, not running FTP, DNS etc. If you were running those services, why on Earth would you run power management anyway?
>As for the thing about Macrovision.......... shit! You've got to be kidding, right?
He's not kidding, and he's actually right as well. I just checked it out in "Video Demystified, a Handbook for the Digital Engineer" by Keith Jack (good book too).
It involves skewing the odd colourburst signal, attenuating sync pulse heights and throwing in extra sync pulses around the place to upset analog VTR'r. Since RGB doesn't have a colour burst, half of the process won't apply.
>I don't know why anyone would prefer YUV over RGB, as the latter is more like what the CRT expects. It's easy enough to change between the two, assuming you have ideal op-amps:-) I guess it must just be an NTSC vs PAL thing.
Thank you, I was waiting for someone to mention SCART and RGB. Here's why.
YUV came about during the transition from black and white sets to colour sets. At that time, only the luminance (Y) needed by the B&W sets was being broadcast. If we were to stop that we would break the B&W sets.
So Luminance was still broadcast, and two colour difference signals (U and V in PAL) were added. B&W sets can carry on using Y, and colour sets can use all three to make an RGB image.
Here's the nifty bit: You can increase/decrease colour saturation simply by amplifying the U and V signals, this would be much harder in RGB.
Yeah, I pretty much agree. Some of the cards I've seen listed here have a pretty crappy max res, it's not like you'd want to pipe your playstation or watch your DV rushes through that, which is why I suggested a monitor of some sorts with more input options a little bit up the thread.
One day, when I can afford it, I'm going to get a projector with component, svideo, dv etc inputs and some nifty video switcher to take care of everything. So far I've got the big white wall.
Documentation wide open and available - hit google to see what I mean, all of their chips have PDF's there for the taking, and on many of them a PCI interface is built into the actualy chip.
There's seems no doubt to me that Brooktree chips will always be well supported under Linux systems, they are so ubiquitous and well documented.
You're bound to be able to find one that's compatible with a MiniDV cam and svideo from the playstation.
I _still_ use an old Commodore 1084S as a monitor for my video machine. Has separate Y/C inputs, component RGB and two handy built in speakers as well.
Surely there's something with as many options still made today?
It would pay to provide a video signal, so the recorder has something to sync to. Without that, it might not run at the right speed. Any stable signal at the native colour format of the VCR should suffice.
All true, yes. I ran Memtestx86 for some 30 hours and no errors were detected. Not only did a kernel compile, but Gentoo has gone through bootstrapping on the machine, a couple of times in fact.
The only point that it would fail is when you emerge xfree. I'm confident I could reproduce it, but I don't want to, of course.
> When you run the same test 5 times, and it gets to the exact same point before sig11ing, you have a software flaw.
Not necessarily: When uncompressing one of the XFree86 source tarballs, X430src-3.tgz, on my old k6 2-450, gzip would always die with a bad CRC. Nothing else at all seemed to go wrong with the machine, but I couldn't uncompress the file until I downed the memory clock to 66MHz, rather than 100.
I found one other person with the same motherboard having the same problem in a google search, and also heard there was a problem with that mainboard using ram at 100MHz.
Yeah, even though a couple of distributors got broken into, well, it happens when you're on 24/7 and known quite well.
Even though I said I found out about vulns in a timely manner, there was still a window of opportunity for me to get 0wnz3r3d. I credit the community for making me aware of things like the OpenSSH vulnerability - Linux isn't self securing on it's own - but if you keep your eye on the ball, you can keep your Linux machine pretty damn secure.
Unless you've been 0wnz3d for weeks, and simply restore the trojans and rootkits with a restore, unless you're using some md5ing on your/etc and other things, or tripwire or whatever.
Slashdot Mirror
Exactly. My point is, whatever forward compatibility XP NTFS has, you can be sure isn't already in the OSS NTFS. It's only stable because it's worked so far. Whatever (as yet unused) forward compat in the current NTFS is exactly the leeway immediately available. Any movement will break OSS NTFS, but not XP. In the meantime, XP can be patched with another NTFS with more goodies.
Now read my second paragraph.
The non-tech public don't need an understanding of a networks underlyings, and at the end of the day he probably did a better job and confused his readers less than many of us would for sure.
Nobody said they'd need to break compat with WinXP. You can be pretty sure the OSS NTFS driver != the WinXP driver. Changes could be made to NTFS that WinXP will survive, but the OSS driver will once again be "Dangerous" to write with. MS won't cop the blame, because it wasn't their driver that trashed it.
You can call it silly paranoia, but if I was motivated by Microsoft's profit margins, I'd do exactly the same thing, because I'm just as greedy and selfish. I'd design the FS primarly for lock-in, (implying covert changes to break compat), secondarily for integrity (because our users suck it up anyway), thirdly for speed.
Nonsense: NTFS is a Windows Filesystem. It's never had to be compatible with anything else, and they've clearly made no effort in letting it be. They have made changes in the past that have had consquences. (I'm not saying they made those changes to be evil, the point is, XP broke Nortons).
And who said they'd need to break XP NTFS to break Linux NTFS? I have no doubt at all the current version of NTFS is already prepared for whatever other layers of obfuscation they might add. Mark my words, NTFS was designed only to allow Windows to store and retrieve files, not you. Windows will be your vehicle for storing and retrieveing those files, they've worked damned hard at making it that way, and they'll continue to work damned hard.
I really must give this Widows software another try. I hear with Vista they're not only going to include security with their products, now you say they're going to thing really hard about what they do in their OS as well!
Seriously, they will think really really hard, they always have. But it's always been more in the interest of their bottom line, not mine or yours.
If they did release an update that trashed 1 or 2 % or Windows installs, they'd release another patch and the public would keep lapping it up.
I can't believe how many years it's taken to reverse NTFS. What does that tell you about a filesystem? It must be so deliberately convolted, arcane and obfuscated to have taken so much effort. The idea of storing data in blocks in a linear address space is nothing new, but somehow I don't think MS stopped when they got a working ACL-based hierachy, otherwise reverse engineering could have been done in a week.
Unless he means to say he really does care about his Karma...?
I think you'd save much more juice just running one PC with enough grunt for what you need.
I would say I'm worried that I've missed your point, but that'd make three posts in a row. All the same, I think you're on crack.
And I'm sure you're familiar with all of the processes involved in turning the water back into its pristine state we began with.
Why, they could surely just pipe the water from the factory outlet back into the factory inlet, right?
I think you might be overlooking something, son. It isn't just shite & piss we're talking about here. Hundreds of different kinds of contaminations, many involving heavy metals.
Yes, I agree completely with you about numbers and statistics, but I don't think the impact of any amount of water contamination, or the effect if it being released unpurified, is seen by you here.
How about: "Don't wake on LAN?"
If it's a client machine, surely no network traffic will be interesting if the machine is unattentded. No point in waking for email, not running FTP, DNS etc. If you were running those services, why on Earth would you run power management anyway?
For the record, how many? Power of 10 will be fine.
He's not kidding, and he's actually right as well. I just checked it out in "Video Demystified, a Handbook for the Digital Engineer" by Keith Jack (good book too).
It involves skewing the odd colourburst signal, attenuating sync pulse heights and throwing in extra sync pulses around the place to upset analog VTR'r. Since RGB doesn't have a colour burst, half of the process won't apply.
Thank you, I was waiting for someone to mention SCART and RGB. Here's why. YUV came about during the transition from black and white sets to colour sets. At that time, only the luminance (Y) needed by the B&W sets was being broadcast. If we were to stop that we would break the B&W sets.
So Luminance was still broadcast, and two colour difference signals (U and V in PAL) were added. B&W sets can carry on using Y, and colour sets can use all three to make an RGB image.
Here's the nifty bit: You can increase/decrease colour saturation simply by amplifying the U and V signals, this would be much harder in RGB.
Also, YUV should compress better
Since you didn't bother to tell me what it is I'll continue to carry on in my ways for now.
Since you remain anonymous, your comment also stands little chance of making it to my .sig
One day, when I can afford it, I'm going to get a projector with component, svideo, dv etc inputs and some nifty video switcher to take care of everything. So far I've got the big white wall.
Documentation wide open and available - hit google to see what I mean, all of their chips have PDF's there for the taking, and on many of them a PCI interface is built into the actualy chip.
There's seems no doubt to me that Brooktree chips will always be well supported under Linux systems, they are so ubiquitous and well documented.
I _still_ use an old Commodore 1084S as a monitor for my video machine. Has separate Y/C inputs, component RGB and two handy built in speakers as well.
Surely there's something with as many options still made today?
It would pay to provide a video signal, so the recorder has something to sync to. Without that, it might not run at the right speed. Any stable signal at the native colour format of the VCR should suffice.
The only point that it would fail is when you emerge xfree. I'm confident I could reproduce it, but I don't want to, of course.
Not necessarily: When uncompressing one of the XFree86 source tarballs, X430src-3.tgz, on my old k6 2-450, gzip would always die with a bad CRC. Nothing else at all seemed to go wrong with the machine, but I couldn't uncompress the file until I downed the memory clock to 66MHz, rather than 100.
I found one other person with the same motherboard having the same problem in a google search, and also heard there was a problem with that mainboard using ram at 100MHz.
Even though I said I found out about vulns in a timely manner, there was still a window of opportunity for me to get 0wnz3r3d. I credit the community for making me aware of things like the OpenSSH vulnerability - Linux isn't self securing on it's own - but if you keep your eye on the ball, you can keep your Linux machine pretty damn secure.
I haven't been r00t3d.
Sweet.