Thats a good partial solution, but it'd be kind of nice to have an open compression format.
For major file formats, it just seems safer to have competing products and a spec out so that more people can make new products. Stuffit is just about the only major-major-major file format on any current platform I know of that's completely closed. Just about every user on the platform runs into Stuffit files, and there's only one commercial product from one company that can create them.
Heck, what if Aladdin started putting adware into Stuffit Expander, or Apple did? They already have "partners" with Sherlock and with default bookmarks...
the old "I built it so I can do whatever I want" argument.
You don't consider that an important freedom -- the ability to build a system however you want? As an engineering type, I certainly would support this.
You have to obey certain consumer safety laws...
Yes, I glossed over these. This is true, but they really don't apply to the situation.
The problem/debate with the DVDs is that many of the mechanisms put in place for them were "piracy prevention" techniques that are being abused by the people who make the media that run on the players.
They were never antipiracy mechanisms. They always were intended to be price discrimination features.
Now, the DMCA makes it illegal to bypass these, but I don't really agree with the DMCA for a lot of reasons. However, I also don't see how manufacturers should be restricted from making systems that you can't figure out how to bypass. If someone made a system that no one could beat that happened to implement region coding...sure, I think that they should have the right to make and sell their system. If consumers really honestly don't like the system, they aren't being forced to buy it.
The BBC gets its revenues...from...government support
I'm not sure that I'd support a tax on everyone to produce TV shows. I'm not a tremendous fan of TV shows, and I wouldn't really want to have to subsidize other people's entertainment. Would you, especially since such a system would probably be democratic...and if soaps and real-world shows were what was popular, you'd be willing to subsidize their production?
There's no really unique new shows coming out because of the need to get those corporate dollars.
That isn't a fundamental flaw in the free market -- the democratic model above would be equally vulnerable to stagnation. Also "really unique new shows" can also really suck. The problem is that it costs a lot of money to start a new show, and when you can put those dollars into making a new show of something that you know that people enjoy, you have to factor in the potential risk. That'd be the same as long as you are trying to maximize enjoyment produced, regardless of who's running the show....DMCA violations...
I don't support the DMCA.
Actually, it was maintained that you in fact can give copies to friends (as long as no money changes hands).
Can you provide a link, please?...mass xeroxing of copyrighted materials is permissable under certain circumstances.
I'm not arguing against fair use laws -- just against existing copyright violation. You and I can both tell the difference between bootlegging 500 Tori Amos CDs and copying pages from a textbook for a college class. And one is legal...and the other isn't.
Regardless of how you build it, once I legally obtain a copy of said information, I'm supposed to be allowed to use it however I please, including viewing partial portions thereof provided I do not infringe upon your rights to copy.
I'm not a proponent of the DMCA, which I think has its own nest of thorns. I do think that using technological solutions like TCPA is quite reasonable. The business doesn't necessarily have the ability to legally prevent you from doing foo, but I think that if they want to do so technologically, more power to them.
Can I use Linux to watch a Disney DVD I've legally purchased on open source DVD playing software?
As long as you aren't violating any normal restrictions (copyright, patent, and contractual), I'm fine with it. As I said, I'm not a huge fan of the DMCA -- though I might find a weakened form accepatable.
Please see the definition of "troll" at everything2.com
Yes? Just because someone is making a comment that *does* happen to be controversial doesn't mean that he's a troll. I think what he's writing was written to make a serious point, not to simply get responses.
That's fine, IF YOU'RE DOING SO on a fair playing field. However, what the MPAA is doing is only allowing selected manufacturers to sell equipment which plays DVDs.
No, that's the DVD Consortium. They made the DVD standard. If they don't want to hand out licenses to their technology, that's their ballgame.
If it really is worthwhile, if consumers really care and artists are really willing to use something other than DVDs, then another format could spring up. I think the problem is that most consumers don't care, most artists want the protection, and the distributors definitely want said protection.
With the DMCA, they have purchased a law which PROHIBITS anyone from making their own products which play DVDs without restrictions
I don't agree with the DMCA, but for different reasons. I don't necessarily think that there's a particularly good reason for you to have a DVD player that can rip video. I think that you have a right to make a new player system (call it BobDVD) that supports a different format that *doesn't* have CSS and friends and doesn't have to have DRM. And if artists and movie houses want to jump on board, they can do it.
However, they ARE lobbying for even more laws to limit my choices in how I can use the content which I have purchased
All they're doing is selling a different product -- a license to use content foo in manner bar. If you don't agree with said manner, or said content, you don't have to purchase their product.
I'm even more concerned about what WILL be illegal if the RIAA/MPAA has their way
I'm not saying that I agree with the RIAA/MPAA. There's lots of things that they want to do that I don't agree with. Just because I don't think that most people have pure intentions when they ask for the ability to rip media doesn't mean that I think that the RIAA/MPAA should be able to impose everything that they *want* to impose. Slippery slope.
Microsoft has the power to impose these restrictions on the ignorant masses, in the guise of improved security or what have you
And you can disable said technologies. No one is forcing them to use them. Now, you won't be able to use some products, but said products were never sold offering you the right to rip them. You aren't forced to buy those products. I fully support the right of companies to sell a crippled product if they want to do so. If the consumer doesn't want it, the consumer doesn't buy. End of story.
You can...for now
Again, slippery slope. I didn't say I would agree with a ban on CD lending.
He's not a troll. His words may be painful, but they sound pretty honest to me.
Do you relish the fact that you can't hit fast forward to skip the advertisements and copyright warnings on DVDs which you've rightfully purchased
I make a product, I can design it to work however I want. If I build the thing to play advertisements, and you still want to buy the thing, that's my decision.
Do you think that the RIAA has the right to impose the cumbersome, fragile CD format on everyone, by attempting to restrict more advanced, convenient means of media storage and playback
Yeah, they've just got a gun to your head and are forcing you to give up said music storage devices. Uh, huh. You can record your own music, or purchase music that isn't owned by them, and put it on your devices however you want. If they want to make a semi-broken "protected" CD, that's their choice, their product, and I don't see where you have any grounds for complaining. No one is forcing you to buy their products.
Do you enjoy being forced to watch commercials on your $50/mo cable TV service
(a) No one is forcing to watch commercials, or for that matter, even purchase TV service from said media companies. I have no interest in TV myself, and would happily not pay for TV service. (b) Would you rather watch TV that costs $50/mo to make? Trust me, it would suck. The commercials may not be entertaining, but unless you're willing to pay with greenbacks instead of being advertised to, the dollars to make the shows have to come from somewhere. It *could* be product placement throughout shows...
Would you prefer that your computer be artifically restricted in what it can and can't do, as opposed to being a general-purpose device whose capability is limited only by the imagination of software engineers?
TCPA/Palladium does *not* do this, dammit. You can use Linux and do whatever you want to with it. No one is forcing you to use Windows, and no one will ever force you to use Windows.
Would you like the federal government to pass laws which restrict you from loaning your favorite book to a friend?
I fail to see how this is relevant. You can load CDs to friends all you want. You just can't make copies of them. You said "loan" the book, not "mass-fucking Xerox" it.
It'd be kind of interesting to support a couple of new tags.
I'd like to see as negatives:
* Factually Inaccurate (people mark incorrect things as "Troll" or "Overrated" currently...just silly.
I'd like to see the "Offtopic" removed as a negative Slashdot moderation. I think that a lot of good conversation threads "spin off" the main thread, and that people unfortunately often get modded as "Offtopic" for material that is quite useful and refreshing.
I also think that there's a reasonable argument that "Overrated" should go. That's really what M2 is for, and having an M2-proof M1 sort of defeats the whole purpose of M2.
and as for good posts, I think that Insightful/Informative/Interesting are overly similar. They get used interchangeably. Perhaps better would be:
Remove Insightful, Informative, and Interesting. They're redundant.
Underrated should go for the same reason that Overrated should.
The following could be added:
* New Information (for posts that introduce additional facts to a story, like "I worked as an engineer at the company and...") * Interesting. Merge of Insightful/Interesting, as the two are not distinguished between by any moderators that I've seen. * Well-written. It would be nice to encourage good syntax on Slashdot. That's one nice thing about kuro5hin -- most users write like professional journalists. Also, there are some really nice things that people make -- relevant haikus, clever bits of story, and the occasional brilliant manifesto -- which really deserve a moderation category of their own.
On the one hand, Stuffit has a really incredibly amazingly good interface. You can navigate through a Stuffit archive like the Finder -- it's hierarchical, supports file operations, etc. WinZip, on the other hand, has a truly amazingly awful interface. Whoever decided that it would be a really cool idea to represent files in a flat interface and then throw a big fat toolbar in (I *hate* toolbars...awful UI element) above them should be whacked.
Anyway, the down side of Stuffit is that it is THE Mac file compression format. Compact Pro has unfortunately fallen by the wayside, and even that contender was, amazingly enough, propriatary. Why the hell can't anyone slap together tar + gzip + macbinary for the MacOS with a GUI (or something a smidgen more complicated, fair enough), so that Mac users aren't beholden to the whims of a single company? If Aladdin wanted to, they could charge $200 for their product. Not for long, but it's disgusting that they have no competition.
Stuffit's had a long history of being exploitable. Hand it corrupted resources and try to open the file...it crashes. Create an archive containing tens of thousands of locked invisible files at the root of the archive (actually, I think Stuffit clears the lock bit, though invis is still valid), and watch what happens when a poor user drops the archive on Stuffit Expander.
Dammit, troll instead of funny? C'mon, have a heart -- the guy was funny.
Oh, well. Here we go.
It's a concrete fact that no MacOS based webserver has ever been hacked into in the history of the internet.
Heh
The MacOS running WebStar and other webservers as hs never been exploited or defaced, and are unbreakable based on ample historical evidence
It's easy to write a secure webserver. It's a little harder to write one that does useful work *and* is secure. I can write a secure webserver in an afternoon. Start adding on forums or something worthwhile to a WebStar server and you'll see security holes.
That is why the US Army gave up on MS IIS and got a Mac for a web server
The Army dropped IIS because it's a bug-laden insecure piece of shit that's been responsible for more break-ins than any other piece of software in the history of mankind. That doesn't mean that Mac OS based webservers are ideal, mate.
I am not talking about FreeBSD derived MacOS X (which already had more than 30 exploits and potential exploits in BugTraq) I am talking about current Mac OS 9.x and earlier which are highly sophisticated abstract-OS models.
Ah, yes. Classic Mac OS. No memory protection, if my memory of 7.x days serves me well. An exploit of the server is an exploit of the whole machine. No chroot.
Why is it hack proof?
Hehe
No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT. Apple uses an object model for process to process communication that is heavily typed and "pipe-less"
You're talking about command line arguments? Doesn't have anything to do with piped communication.
No root user. All mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stuff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root there is no false sense of security, and programming is done carefully.
Yeah, I did development on System 7.x for a while. It does teach you to be damn careful with those pointers -- crash "Damn, gotta reboot so I can change one line, recompile, and try again!". I don't buy it.
Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The mac avoids C strings historically in most of all of its OS. In fact even its roms originally used Pascal strings. As you know pascal strings are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL) but the side effect is less buffer exploits. Individual 3rd party products may use C sings and bind to ANSI libraries, but many do not. In case you are not aware of what a "pascal string" is, it usually has no null byte terminator
Pascal strings are a fucking archaic scheme dating from times when you statically allocated 255 byte strings and then had a size byte to tell you how much you were actually using. They cap you at 255 bytes. You can do bounds-checked arrays in C, just as you can in Pascal. Not everyone does so, but the same applies to the Mac and Pascal strings, as you pointed out. Furthermore, using UNIX or Windows doesn't mean that you have to use C/C++. In the GNU Compiler Collection alone, you have Java, fortran 77, objective C (*cough* like MacOS X), and Ada support, all of which have bounds-checked strings.
Macs running Webstar have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension). File types on macs are not easily settable by users, especially remotely. Apache as you know has had many problems in earlier years preventing wayward execution.
Yeah? And UNIX has an executable bit. If someone can get it and flip permission bits and rename files, the chances are pretty good that they can change file types.
Macs never run code ever merely based on how a file is named. ".exe" suffixes mean nothing! For example the file type is 4 characters of user-invisible attributes, along with many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For example file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable by design of creating an executable file. The file type is not set to executable for the hacker's needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if they had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually. TOTAL security.
This is why every communication program for the Mac supports MacBinary. If you can upload something to the system, you can pretty assuredly toss a resource fork up.
Stack return addresses positioned in safer location than some intel OSes. Buffer exploits take advantage of loser programers lack of string length checking and clobber the return address to run their exploit code instead. The Mac compilers usually place return address in front or out of context of where the buffer would overrun. Much safer.
There are less macs, though there are huge cash prizes for cracking into a MacOS based WebStar server (typically over $10,000 US)
This happened *once*, laddie buck.
Less macs mean less hacker interest, but there are MILLIONS of macs sold, and some of the most skilled programmers are well versed in systems level mac engineering and know of the cash prizes, so its a moot point, but perhaps macs are never kracked because there appear to be less of them.
Some of the most skilled programmers are systems level Mac coders? I mean, it's not *impossible*, but is there a Archangeli or a Cox in the MacOS world? If there is, they likely work for Apple and aren't out trying to break into web servers.
But some huge high performance sites use load-balancing webstar.
Why should you *not* use a classic Mac for a high-powered server?
Let's see. If we have more than one process doing anything on the system, we run into the complete lack of preemptive multitasking. If an administrator is doing something at the console, everything except for interrupt-driven crap stops cold. Bit of an issue. There's the lousy VM in the classic Mac OS. HFS/HFS+ is not the most impressively high performance filesystem ever. Caching in the classic Mac OS sucks.
Classic Mac OS was designed to be a workstation. Servers were not in the mind of the designers at all. That doesn't matter -- it makes a fine workstation for many people. But pimping it as a server is silly.
MacOS source not available traditionally, except within apple, similar to Microsoft source only available to its summer interns and engineers, source is rare to MacOS. This makes it hard to look fo rprogramming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
So by your logic, there should be no IIS exploits.
Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is
People who install Apache are fools?...other than that event ages ago in 1995, no mac web server has ever been...scanned...
I really hate to break this to you, but you're in error here.
I think its quite amusing that there are over 200 or 300 known vulnerabilities in RedHat over the years and not one MacOS 9.x or older remote exploit hack. There are even vulnerabilities a month ago in OpenBSD! Each month vulnerabilities in XP arise.
Those 200 to 300 vulnerabilities you list are *local* exploits, you idiot. Classic Mac OS doesn't list those because by using the computer you are engaging in one giant exploit...able to read other users files and whatnot. If Apple was as ambitious as Red Hat is, they'd be listing "local vulnerabilities" as well. Apple doesn't go out of their way to point out holes that they *do* have. Furthermore, Red Hat ships with *servers* to exploit. The Mac OS doesn't *do* anything out of box as regards serving, so there isn't much to exploit. If you don't care about doing anything, an off computer is even more secure.
BTW, I distinctly remember Apple never shipping a free update to Open Transport to fix some vulnerabilities in the TCP implementation for those of us with System 7.5.x. That *is* attackable.
Let's look at your post from how you would feel if someone aimed this at you -- I think you'll find it a bit harsh.
"The problem I have with posts on Slashdot making personal attacks, is that there is no context for the attack. Specifically, blah blah blah. We have no knowledge of the posters skill level or experience.
It would be far better if the poster would give a little background information about themselves, along with the post.
What is FreeLinux's skill level? How long has he worked in this field? What related hardware and software is he proficient with? What other books on the subject has this person read and what was their opinion of one of those books? Without this information the post carries no more weight than one from Jon Katz."
Ah, but you have to use both hands to browse the web -- they only need one. The initial target market for this is compulsive masturbaters. If penetration is deep enough, they expect to move to one-handed Vietnam veterans and people trying to make good on "I could do that with one hand behind my back" bar bets.
Other potential markets include users of hand-crank-generator-powered computers (which have one hand tied up at all times) and computer users too dense to manage a keyboard.
Re:Compiling mplayer (was: Save your bandwidth)
on
Red Hat 8.0 Released
·
· Score: 2
If you want the very minimal out of mplayer, yes. If you're trying to get it to run w/o blowing CPU cycles out the window (like me, with a PII/266):
Try to compile, find what isn't enabled, track down missing libraries, some of which have probably never been used by any other software package. Figure out how to build and install each. Get avcodec from CVS (as per mplayer documentation), manually copy it into the mplayer directory, build, find out that it doesn't compile, obtain snapshot, manually copy that in and compile. Tell./configure in the mplayer package manually about all the locations of libraries that have decided to install elsewhere from where mplayer is looking for them.
Download a font. Run script that generates font description files and font files, which you manually copy to your home mplayer directory. Set up rc file so that proper hardware acceleration is used. Compile and install kernel module for x-based matrox card. Realize that said kernel module is incompatible with devfs -- write a patch, submit, compiled the fixed version. Tell devfs about the permissions on said device by writing a few more lines manually to its config file. Ensure that mtrrs are set up on your X install (not an issue anymore with XF86 4.x era stuff). Realize that non-root (even suid to root) cannot use the RTC for timing, thanks to stupid check-for-root code in the kernel -- start su'ing every time you want to play a movie. Figure out how the hell to get the thing working with alsa.9 branch and how the hell to make it play out your *second* sound card instead if your first.
Now we can start finding codecs. Download various versions of divx4linux/divx5linux, discover that only one works properly, another simply causes segfaults, and the last plays properly most of the time but tints everything green and occasionally can't understand frames. Download Windows codecs, figure out how to tell mplayer *not* to use the Windows codecs by default to keep speed at a sane rate (but you want 'em if you're working with a codec with no native support). Set up permissions on said things.
Note: I haven't even bothered trying to get a GUI working for this, which would involve skins and whatnot.
Mplayer is a sweet piece of software, but boy is it a PITA to build properly. I think the only piece of software that I've spent more time trying to get working properly is iptables.
They kept getting expensive irate "customers" who bought CheapBytes CDs and wanted the customer install support that only comes with Red Hat's $50 commercial product.
I think that's pretty generous. They're letting people use all the software they made, but they've gotten fed up with support requests from confused people who bought "Red Hat" CDs from CheapBytes. If you want that support, slap down your five tens.
I will grant that PDF can store scanned documents, but it's really designed and best for storing printed-directly-to-PDF files...otherwise, you end up with absolutely massive files. Unfortunately, it's commonly used for said purpose. Even PNG would be much better.
DjVu is an interesting format that was primarily designed for storing scanned formats.
It uses a couple of techniques, such as OCR/pseudo-OCR, and multiple embedded images (JPEG/PNG) within the file for rasterable images. The idea is that, say, a scanned magazine page with text and a photographic image is stored as text, a little bit of outline font information, and a JPEG of the photographic image.
Yes, I've noticed how downloading and installing xmms is is truly Herculean task.
Now, I *will* grant that compiling mplayer from source, as you really should do, is at least a couple notches closer to "Herculean", but that's always been the case.
I've tried with 1.2.0a and CVS over a period of time. It seems to work with older clients, just not new ones.
I'm not saying that it's the fault of the licq coders, or that Mirabilis is innocent. I'm just saying that when I have to resort to workarounds (like FTP) to get files to a Windows user, it gives them a pretty negative impression of Linux.
Licq can message fairly reliably...just not transfer files.
Aside from that, trying to get everyone to flip a setting in their preferences so that they can "talk to Linux computers" still doesn't look that great.
Normally, Linux mounts its filesystems with atimes on. Each file has a timestamp recording the last time the file was accessed.
If you drop in noatime into/etc/fstab, this behavior is disabled.
Some people *really* like this behavior -- it lets you keep track of which files aren't used much.
I really *don't* like this behavior. Some utilities, like tail, keep polling a file and updating its atime, so the Linux box keeps writing to the disk every couple of seconds (obviously, tuneable via the VM settings, but I *like* flushing my buffers each few seconds). In a quiet room, this is really annoying. Also, I rarely care about atimes, because I frequently do find -type f |xargs grep operations that cover large chunks of my disk and set the atimes on everything to the current time -- I'm more interested in "last modified" times.
It doesn't actually slow down the box that much (well, I haven't actually benchmarked it, but I suspect that it isn't that bad, even if you did something like find -type f |xargs file, which is about the worst thing I can think of. But it produces extra traffic to the disk that doesn't do me any good.
Yes, but there's another good reason to use -O3. Trying to optimize C across function boundaries is extremely limiting. If you can inline a function, you can do far better optimization.
You can do so much more in PS 6 than in Gimp - balloon, scrunch, drop shadow with a click, outline, gradient overlay, pattern overlay, inner shadow, etc.
So? You could do this for years with plugins for earlier version of Photoshop, or by hand. Same goes for the Gimp.
The Gimp does nothing but RGB and has basically no for-press features, just stuff designed to make nice online output. It sucks for making things intended for print output. That pretty much sums up its failings. In terms of features for making output designed for online use, the Gimp is just as good as Photoshop.
Also, if you like *Photoshop* palettes, take a look at the development branch of the Gimp...mmm, tasty.
I'd rather see this implemented in ext3 than ext2 for the obvious journalling benefits
Okay. First, implementing this in ext3 would be almost meaningless. The entire point of journalling is that you always write *forward* on the disk, and update pointers to the newest data. Your writes are nearly always contiguous in ext3. This system, where you have to overwrite positions containing deleted files, would have to dance from location to location on the disk to write a file. Very expensive. You could make an atomic writes filesystem, but it probably wouldn't be smart to make it journalling.
Also, I definitely do not feel that a performance hit would be noticeable. The Novell file system is still BLAZING fast despite the fact taht it is managing hundreds of thousands of deleted files
The number of deleted files isn't the issue -- it's how much free space you have available. I can assure you that the Novell guys aren't taking your approach -- only overwriting something when they absolutely have to do so.
The filesystem would still control fragmentation, just as it does today.
What impact does this have on performance? If you're thinking that ext2 does background defragmentation, it doesn't.
The fragmentation issues stem entirely from the lack of free space -- the file system always has an extremely small amount of free space. That free space is likely scattered around the disk.
I'm not sure of all the ways that ext2 differs from vanilla UFS, but I strongly suspect that ext2 does not have a distinct allocated block list. In any event, a one-table or two-table question really isn't an issue.
Finally, let me reiterate: FREE SPACE. Between about 80% or 90% full, ext2/3 filesystem performance starts to take a nasty hit from fragmentation. If your filesystem is 99% full, you're going to be getting quite fragmented. If you are using the proposed system, you always have just a few killobytes of free space (the space left over in what used to be the oldest deleted file).
The "twin file tables system", as far as I can tell, used a minimal-overwite algorithm -- overwrite absolutely no more files than is necessary.
That's expensive. That *will* fragment files badly.
Now, say you propose defragging on the fly. If you have a fragmented series of files, you have to defrag on the fly while doing writes. Plus, your disk is essentially always 100% full, *and* to make this a sane system, all of your operations have to be atomic. This is a worst-case scenerio for defragmentation. If you've ever tried defragging a full FAT32 filesystem, you know what I'm talking about.
So what *used* to be slapping a chunk of data down onto a disk now becomes a number of moves of data to defragment files, plus your initial write. These defragmentation moves need to be atomic, so you need to be writing some other metadata on the disk. Not only that, we're doing *far* more seeking. Seeking is mind-blowingly expensive compared to writing that chunk of data from before, and the fact that we have to flush the buffers frequently to keep things atomic means that we can't combine as many writes, which means worse seeking.
Without a real world implementation with numbers, it's hard to show you how bad this would be, but every filesystem I've ever used would be far, far, far faster than this.
Slashdot Mirror
If someone with known allergies to *peanuts* buys and eats *peanut butter*, forget the warning requirements. They *deserve* what they get.
I mean, I got a cup the other day that said "WARNING! CONTENTS MAY BE HOT! SIP CAREFULLY!". What the hell happened to common sense?
Thats a good partial solution, but it'd be kind of nice to have an open compression format.
For major file formats, it just seems safer to have competing products and a spec out so that more people can make new products. Stuffit is just about the only major-major-major file format on any current platform I know of that's completely closed. Just about every user on the platform runs into Stuffit files, and there's only one commercial product from one company that can create them.
Heck, what if Aladdin started putting adware into Stuffit Expander, or Apple did? They already have "partners" with Sherlock and with default bookmarks...
the old "I built it so I can do whatever I want" argument.
...DMCA violations...
...mass xeroxing of copyrighted materials is permissable under certain circumstances.
You don't consider that an important freedom -- the ability to build a system however you want? As an engineering type, I certainly would support this.
You have to obey certain consumer safety laws...
Yes, I glossed over these. This is true, but they really don't apply to the situation.
The problem/debate with the DVDs is that many of the mechanisms put in place for them were "piracy prevention" techniques that are being abused by the people who make the media that run on the players.
They were never antipiracy mechanisms. They always were intended to be price discrimination features.
Now, the DMCA makes it illegal to bypass these, but I don't really agree with the DMCA for a lot of reasons. However, I also don't see how manufacturers should be restricted from making systems that you can't figure out how to bypass. If someone made a system that no one could beat that happened to implement region coding...sure, I think that they should have the right to make and sell their system. If consumers really honestly don't like the system, they aren't being forced to buy it.
The BBC gets its revenues...from...government support
I'm not sure that I'd support a tax on everyone to produce TV shows. I'm not a tremendous fan of TV shows, and I wouldn't really want to have to subsidize other people's entertainment. Would you, especially since such a system would probably be democratic...and if soaps and real-world shows were what was popular, you'd be willing to subsidize their production?
There's no really unique new shows coming out because of the need to get those corporate dollars.
That isn't a fundamental flaw in the free market -- the democratic model above would be equally vulnerable to stagnation. Also "really unique new shows" can also really suck. The problem is that it costs a lot of money to start a new show, and when you can put those dollars into making a new show of something that you know that people enjoy, you have to factor in the potential risk. That'd be the same as long as you are trying to maximize enjoyment produced, regardless of who's running the show.
I don't support the DMCA.
Actually, it was maintained that you in fact can give copies to friends (as long as no money changes hands).
Can you provide a link, please?
I'm not arguing against fair use laws -- just against existing copyright violation. You and I can both tell the difference between bootlegging 500 Tori Amos CDs and copying pages from a textbook for a college class. And one is legal...and the other isn't.
when you BUY a product, you can DO WHAT YOU WANT WITH IT!!
But the manufacturer is not required to facilitate said activities.
I don't favor the DMCA. TCPA/Palladium, though, is fine in my book.
Regardless of how you build it, once I legally obtain a copy of said information, I'm supposed to be allowed to use it however I please, including viewing partial portions thereof provided I do not infringe upon your rights to copy.
I'm not a proponent of the DMCA, which I think has its own nest of thorns. I do think that using technological solutions like TCPA is quite reasonable. The business doesn't necessarily have the ability to legally prevent you from doing foo, but I think that if they want to do so technologically, more power to them.
Can I use Linux to watch a Disney DVD I've legally purchased on open source DVD playing software?
As long as you aren't violating any normal restrictions (copyright, patent, and contractual), I'm fine with it. As I said, I'm not a huge fan of the DMCA -- though I might find a weakened form accepatable.
Please see the definition of "troll" at everything2.com
Yes? Just because someone is making a comment that *does* happen to be controversial doesn't mean that he's a troll. I think what he's writing was written to make a serious point, not to simply get responses.
That's fine, IF YOU'RE DOING SO on a fair playing field. However, what the MPAA is doing is only allowing selected manufacturers to sell equipment which plays DVDs.
No, that's the DVD Consortium. They made the DVD standard. If they don't want to hand out licenses to their technology, that's their ballgame.
If it really is worthwhile, if consumers really care and artists are really willing to use something other than DVDs, then another format could spring up. I think the problem is that most consumers don't care, most artists want the protection, and the distributors definitely want said protection.
With the DMCA, they have purchased a law which PROHIBITS anyone from making their own products which play DVDs without restrictions
I don't agree with the DMCA, but for different reasons. I don't necessarily think that there's a particularly good reason for you to have a DVD player that can rip video. I think that you have a right to make a new player system (call it BobDVD) that supports a different format that *doesn't* have CSS and friends and doesn't have to have DRM. And if artists and movie houses want to jump on board, they can do it.
However, they ARE lobbying for even more laws to limit my choices in how I can use the content which I have purchased
All they're doing is selling a different product -- a license to use content foo in manner bar. If you don't agree with said manner, or said content, you don't have to purchase their product.
I'm even more concerned about what WILL be illegal if the RIAA/MPAA has their way
I'm not saying that I agree with the RIAA/MPAA. There's lots of things that they want to do that I don't agree with. Just because I don't think that most people have pure intentions when they ask for the ability to rip media doesn't mean that I think that the RIAA/MPAA should be able to impose everything that they *want* to impose. Slippery slope.
Microsoft has the power to impose these restrictions on the ignorant masses, in the guise of improved security or what have you
And you can disable said technologies. No one is forcing them to use them. Now, you won't be able to use some products, but said products were never sold offering you the right to rip them. You aren't forced to buy those products. I fully support the right of companies to sell a crippled product if they want to do so. If the consumer doesn't want it, the consumer doesn't buy. End of story.
You can...for now
Again, slippery slope. I didn't say I would agree with a ban on CD lending.
I'll feed the troll
He's not a troll. His words may be painful, but they sound pretty honest to me.
Do you relish the fact that you can't hit fast forward to skip the advertisements and copyright warnings on DVDs which you've rightfully purchased
I make a product, I can design it to work however I want. If I build the thing to play advertisements, and you still want to buy the thing, that's my decision.
Do you think that the RIAA has the right to impose the cumbersome, fragile CD format on everyone, by attempting to restrict more advanced, convenient means of media storage and playback
Yeah, they've just got a gun to your head and are forcing you to give up said music storage devices. Uh, huh. You can record your own music, or purchase music that isn't owned by them, and put it on your devices however you want. If they want to make a semi-broken "protected" CD, that's their choice, their product, and I don't see where you have any grounds for complaining. No one is forcing you to buy their products.
Do you enjoy being forced to watch commercials on your $50/mo cable TV service
(a) No one is forcing to watch commercials, or for that matter, even purchase TV service from said media companies. I have no interest in TV myself, and would happily not pay for TV service. (b) Would you rather watch TV that costs $50/mo to make? Trust me, it would suck. The commercials may not be entertaining, but unless you're willing to pay with greenbacks instead of being advertised to, the dollars to make the shows have to come from somewhere. It *could* be product placement throughout shows...
Would you prefer that your computer be artifically restricted in what it can and can't do, as opposed to being a general-purpose device whose capability is limited only by the imagination of software engineers?
TCPA/Palladium does *not* do this, dammit. You can use Linux and do whatever you want to with it. No one is forcing you to use Windows, and no one will ever force you to use Windows.
Would you like the federal government to pass laws which restrict you from loaning your favorite book to a friend?
I fail to see how this is relevant. You can load CDs to friends all you want. You just can't make copies of them. You said "loan" the book, not "mass-fucking Xerox" it.
It'd be kind of interesting to support a couple of new tags.
I'd like to see as negatives:
* Factually Inaccurate (people mark incorrect things as "Troll" or "Overrated" currently...just silly.
I'd like to see the "Offtopic" removed as a negative Slashdot moderation. I think that a lot of good conversation threads "spin off" the main thread, and that people unfortunately often get modded as "Offtopic" for material that is quite useful and refreshing.
I also think that there's a reasonable argument that "Overrated" should go. That's really what M2 is for, and having an M2-proof M1 sort of defeats the whole purpose of M2.
and as for good posts, I think that Insightful/Informative/Interesting are overly similar. They get used interchangeably. Perhaps better would be:
Remove Insightful, Informative, and Interesting. They're redundant.
Underrated should go for the same reason that Overrated should.
The following could be added:
* New Information (for posts that introduce additional facts to a story, like "I worked as an engineer at the company and...")
* Interesting. Merge of Insightful/Interesting, as the two are not distinguished between by any moderators that I've seen.
* Well-written. It would be nice to encourage good syntax on Slashdot. That's one nice thing about kuro5hin -- most users write like professional journalists. Also, there are some really nice things that people make -- relevant haikus, clever bits of story, and the occasional brilliant manifesto -- which really deserve a moderation category of their own.
Thoughts, anyone?
I've always had sort of a dim view of StuffIt.
On the one hand, Stuffit has a really incredibly amazingly good interface. You can navigate through a Stuffit archive like the Finder -- it's hierarchical, supports file operations, etc. WinZip, on the other hand, has a truly amazingly awful interface. Whoever decided that it would be a really cool idea to represent files in a flat interface and then throw a big fat toolbar in (I *hate* toolbars...awful UI element) above them should be whacked.
Anyway, the down side of Stuffit is that it is THE Mac file compression format. Compact Pro has unfortunately fallen by the wayside, and even that contender was, amazingly enough, propriatary. Why the hell can't anyone slap together tar + gzip + macbinary for the MacOS with a GUI (or something a smidgen more complicated, fair enough), so that Mac users aren't beholden to the whims of a single company? If Aladdin wanted to, they could charge $200 for their product. Not for long, but it's disgusting that they have no competition.
Stuffit's had a long history of being exploitable. Hand it corrupted resources and try to open the file...it crashes. Create an archive containing tens of thousands of locked invisible files at the root of the archive (actually, I think Stuffit clears the lock bit, though invis is still valid), and watch what happens when a poor user drops the archive on Stuffit Expander.
Dammit, troll instead of funny? C'mon, have a heart -- the guy was funny.
...other than that event ages ago in 1995, no mac web server has ever been...scanned...
Oh, well. Here we go.
It's a concrete fact that no MacOS based webserver has ever been hacked into in the history of the internet.
Heh
The MacOS running WebStar and other webservers as hs never been exploited or defaced, and are unbreakable based on ample historical evidence
It's easy to write a secure webserver. It's a little harder to write one that does useful work *and* is secure. I can write a secure webserver in an afternoon. Start adding on forums or something worthwhile to a WebStar server and you'll see security holes.
That is why the US Army gave up on MS IIS and got a Mac for a web server
The Army dropped IIS because it's a bug-laden insecure piece of shit that's been responsible for more break-ins than any other piece of software in the history of mankind. That doesn't mean that Mac OS based webservers are ideal, mate.
I am not talking about FreeBSD derived MacOS X (which already had more than 30 exploits and potential exploits in BugTraq) I am talking about current Mac OS 9.x and earlier which are highly sophisticated abstract-OS models.
Ah, yes. Classic Mac OS. No memory protection, if my memory of 7.x days serves me well. An exploit of the server is an exploit of the whole machine. No chroot.
Why is it hack proof?
Hehe
No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT. Apple uses an object model for process to process communication that is heavily typed and "pipe-less"
You're talking about command line arguments? Doesn't have anything to do with piped communication.
No root user. All mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stuff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root there is no false sense of security, and programming is done carefully.
Yeah, I did development on System 7.x for a while. It does teach you to be damn careful with those pointers -- crash "Damn, gotta reboot so I can change one line, recompile, and try again!". I don't buy it.
Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The mac avoids C strings historically in most of all of its OS. In fact even its roms originally used Pascal strings. As you know pascal strings are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL) but the side effect is less buffer exploits. Individual 3rd party products may use C sings and bind to ANSI libraries, but many do not. In case you are not aware of what a "pascal string" is, it usually has no null byte terminator
Pascal strings are a fucking archaic scheme dating from times when you statically allocated 255 byte strings and then had a size byte to tell you how much you were actually using. They cap you at 255 bytes. You can do bounds-checked arrays in C, just as you can in Pascal. Not everyone does so, but the same applies to the Mac and Pascal strings, as you pointed out. Furthermore, using UNIX or Windows doesn't mean that you have to use C/C++. In the GNU Compiler Collection alone, you have Java, fortran 77, objective C (*cough* like MacOS X), and Ada support, all of which have bounds-checked strings.
Macs running Webstar have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension). File types on macs are not easily settable by users, especially remotely. Apache as you know has had many problems in earlier years preventing wayward execution.
Yeah? And UNIX has an executable bit. If someone can get it and flip permission bits and rename files, the chances are pretty good that they can change file types.
Macs never run code ever merely based on how a file is named. ".exe" suffixes mean nothing! For example the file type is 4 characters of user-invisible attributes, along with many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For example file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable by design of creating an executable file. The file type is not set to executable for the hacker's needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if they had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually. TOTAL security.
This is why every communication program for the Mac supports MacBinary. If you can upload something to the system, you can pretty assuredly toss a resource fork up.
Stack return addresses positioned in safer location than some intel OSes. Buffer exploits take advantage of loser programers lack of string length checking and clobber the return address to run their exploit code instead. The Mac compilers usually place return address in front or out of context of where the buffer would overrun. Much safer.
Take a look at the first link on this Google search. Secure or not?
There are less macs, though there are huge cash prizes for cracking into a MacOS based WebStar server (typically over $10,000 US)
This happened *once*, laddie buck.
Less macs mean less hacker interest, but there are MILLIONS of macs sold, and some of the most skilled programmers are well versed in systems level mac engineering and know of the cash prizes, so its a moot point, but perhaps macs are never kracked because there appear to be less of them.
Some of the most skilled programmers are systems level Mac coders? I mean, it's not *impossible*, but is there a Archangeli or a Cox in the MacOS world? If there is, they likely work for Apple and aren't out trying to break into web servers.
But some huge high performance sites use load-balancing webstar.
Why should you *not* use a classic Mac for a high-powered server?
Let's see. If we have more than one process doing anything on the system, we run into the complete lack of preemptive multitasking. If an administrator is doing something at the console, everything except for interrupt-driven crap stops cold. Bit of an issue. There's the lousy VM in the classic Mac OS. HFS/HFS+ is not the most impressively high performance filesystem ever. Caching in the classic Mac OS sucks.
Classic Mac OS was designed to be a workstation. Servers were not in the mind of the designers at all. That doesn't matter -- it makes a fine workstation for many people. But pimping it as a server is silly.
MacOS source not available traditionally, except within apple, similar to Microsoft source only available to its summer interns and engineers, source is rare to MacOS. This makes it hard to look fo rprogramming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
So by your logic, there should be no IIS exploits.
Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is
People who install Apache are fools?
I really hate to break this to you, but you're in error here.
I think its quite amusing that there are over 200 or 300 known vulnerabilities in RedHat over the years and not one MacOS 9.x or older remote exploit hack. There are even vulnerabilities a month ago in OpenBSD! Each month vulnerabilities in XP arise.
Those 200 to 300 vulnerabilities you list are *local* exploits, you idiot. Classic Mac OS doesn't list those because by using the computer you are engaging in one giant exploit...able to read other users files and whatnot. If Apple was as ambitious as Red Hat is, they'd be listing "local vulnerabilities" as well. Apple doesn't go out of their way to point out holes that they *do* have. Furthermore, Red Hat ships with *servers* to exploit. The Mac OS doesn't *do* anything out of box as regards serving, so there isn't much to exploit. If you don't care about doing anything, an off computer is even more secure.
BTW, I distinctly remember Apple never shipping a free update to Open Transport to fix some vulnerabilities in the TCP implementation for those of us with System 7.5.x. That *is* attackable.
Let's look at your post from how you would feel if someone aimed this at you -- I think you'll find it a bit harsh.
"The problem I have with posts on Slashdot making personal attacks, is that there is no context for the attack. Specifically, blah blah blah. We have no knowledge of the posters skill level or experience.
It would be far better if the poster would give a little background information about themselves, along with the post.
What is FreeLinux's skill level? How long has he worked in this field? What related hardware and software is he proficient with? What other books on the subject has this person read and what was their opinion of one of those books? Without this information the post carries no more weight than one from Jon Katz."
Ah, but you have to use both hands to browse the web -- they only need one. The initial target market for this is compulsive masturbaters. If penetration is deep enough, they expect to move to one-handed Vietnam veterans and people trying to make good on "I could do that with one hand behind my back" bar bets.
Other potential markets include users of hand-crank-generator-powered computers (which have one hand tied up at all times) and computer users too dense to manage a keyboard.
If you want the very minimal out of mplayer, yes. If you're trying to get it to run w/o blowing CPU cycles out the window (like me, with a PII/266):
./configure in the mplayer package manually about all the locations of libraries that have decided to install elsewhere from where mplayer is looking for them.
.9 branch and how the hell to make it play out your *second* sound card instead if your first.
Try to compile, find what isn't enabled, track down missing libraries, some of which have probably never been used by any other software package. Figure out how to build and install each. Get avcodec from CVS (as per mplayer documentation), manually copy it into the mplayer directory, build, find out that it doesn't compile, obtain snapshot, manually copy that in and compile. Tell
Download a font. Run script that generates font description files and font files, which you manually copy to your home mplayer directory. Set up rc file so that proper hardware acceleration is used. Compile and install kernel module for x-based matrox card. Realize that said kernel module is incompatible with devfs -- write a patch, submit, compiled the fixed version. Tell devfs about the permissions on said device by writing a few more lines manually to its config file. Ensure that mtrrs are set up on your X install (not an issue anymore with XF86 4.x era stuff). Realize that non-root (even suid to root) cannot use the RTC for timing, thanks to stupid check-for-root code in the kernel -- start su'ing every time you want to play a movie. Figure out how the hell to get the thing working with alsa
Now we can start finding codecs. Download various versions of divx4linux/divx5linux, discover that only one works properly, another simply causes segfaults, and the last plays properly most of the time but tints everything green and occasionally can't understand frames. Download Windows codecs, figure out how to tell mplayer *not* to use the Windows codecs by default to keep speed at a sane rate (but you want 'em if you're working with a codec with no native support). Set up permissions on said things.
Note: I haven't even bothered trying to get a GUI working for this, which would involve skins and whatnot.
Mplayer is a sweet piece of software, but boy is it a PITA to build properly. I think the only piece of software that I've spent more time trying to get working properly is iptables.
They kept getting expensive irate "customers" who bought CheapBytes CDs and wanted the customer install support that only comes with Red Hat's $50 commercial product.
I think that's pretty generous. They're letting people use all the software they made, but they've gotten fed up with support requests from confused people who bought "Red Hat" CDs from CheapBytes. If you want that support, slap down your five tens.
I will grant that PDF can store scanned documents, but it's really designed and best for storing printed-directly-to-PDF files...otherwise, you end up with absolutely massive files. Unfortunately, it's commonly used for said purpose. Even PNG would be much better.
DjVu is an interesting format that was primarily designed for storing scanned formats.
It uses a couple of techniques, such as OCR/pseudo-OCR, and multiple embedded images (JPEG/PNG) within the file for rasterable images. The idea is that, say, a scanned magazine page with text and a photographic image is stored as text, a little bit of outline font information, and a JPEG of the photographic image.
Yes, I've noticed how downloading and installing xmms is is truly Herculean task.
Now, I *will* grant that compiling mplayer from source, as you really should do, is at least a couple notches closer to "Herculean", but that's always been the case.
Rsync might have let you get the "corrupted" bits without downloading the whole thing again.
I've tried with 1.2.0a and CVS over a period of time. It seems to work with older clients, just not new ones.
I'm not saying that it's the fault of the licq coders, or that Mirabilis is innocent. I'm just saying that when I have to resort to workarounds (like FTP) to get files to a Windows user, it gives them a pretty negative impression of Linux.
And AIM doing it doesn't help either...
I've done that already.
Licq can message fairly reliably...just not transfer files.
Aside from that, trying to get everyone to flip a setting in their preferences so that they can "talk to Linux computers" still doesn't look that great.
Normally, Linux mounts its filesystems with atimes on. Each file has a timestamp recording the last time the file was accessed.
/etc/fstab, this behavior is disabled.
If you drop in noatime into
Some people *really* like this behavior -- it lets you keep track of which files aren't used much.
I really *don't* like this behavior. Some utilities, like tail, keep polling a file and updating its atime, so the Linux box keeps writing to the disk every couple of seconds (obviously, tuneable via the VM settings, but I *like* flushing my buffers each few seconds). In a quiet room, this is really annoying. Also, I rarely care about atimes, because I frequently do find -type f |xargs grep operations that cover large chunks of my disk and set the atimes on everything to the current time -- I'm more interested in "last modified" times.
It doesn't actually slow down the box that much (well, I haven't actually benchmarked it, but I suspect that it isn't that bad, even if you did something like find -type f |xargs file, which is about the worst thing I can think of. But it produces extra traffic to the disk that doesn't do me any good.
Yes, but there's another good reason to use -O3. Trying to optimize C across function boundaries is extremely limiting. If you can inline a function, you can do far better optimization.
You can do so much more in PS 6 than in Gimp - balloon, scrunch, drop shadow with a click, outline, gradient overlay, pattern overlay, inner shadow, etc.
So? You could do this for years with plugins for earlier version of Photoshop, or by hand. Same goes for the Gimp.
The Gimp does nothing but RGB and has basically no for-press features, just stuff designed to make nice online output. It sucks for making things intended for print output. That pretty much sums up its failings. In terms of features for making output designed for online use, the Gimp is just as good as Photoshop.
Also, if you like *Photoshop* palettes, take a look at the development branch of the Gimp...mmm, tasty.
ARRRRRGGGGHHHH!
I'd rather see this implemented in ext3 than ext2 for the obvious journalling benefits
Okay. First, implementing this in ext3 would be almost meaningless. The entire point of journalling is that you always write *forward* on the disk, and update pointers to the newest data. Your writes are nearly always contiguous in ext3. This system, where you have to overwrite positions containing deleted files, would have to dance from location to location on the disk to write a file. Very expensive. You could make an atomic writes filesystem, but it probably wouldn't be smart to make it journalling.
Also, I definitely do not feel that a performance hit would be noticeable. The Novell file system is still BLAZING fast despite the fact taht it is managing hundreds of thousands of deleted files
The number of deleted files isn't the issue -- it's how much free space you have available. I can assure you that the Novell guys aren't taking your approach -- only overwriting something when they absolutely have to do so.
The filesystem would still control fragmentation, just as it does today.
What impact does this have on performance? If you're thinking that ext2 does background defragmentation, it doesn't.
The fragmentation issues stem entirely from the lack of free space -- the file system always has an extremely small amount of free space. That free space is likely scattered around the disk.
I'm not sure of all the ways that ext2 differs from vanilla UFS, but I strongly suspect that ext2 does not have a distinct allocated block list. In any event, a one-table or two-table question really isn't an issue.
Finally, let me reiterate: FREE SPACE. Between about 80% or 90% full, ext2/3 filesystem performance starts to take a nasty hit from fragmentation. If your filesystem is 99% full, you're going to be getting quite fragmented. If you are using the proposed system, you always have just a few killobytes of free space (the space left over in what used to be the oldest deleted file).
The "twin file tables system", as far as I can tell, used a minimal-overwite algorithm -- overwrite absolutely no more files than is necessary.
That's expensive. That *will* fragment files badly.
Now, say you propose defragging on the fly. If you have a fragmented series of files, you have to defrag on the fly while doing writes. Plus, your disk is essentially always 100% full, *and* to make this a sane system, all of your operations have to be atomic. This is a worst-case scenerio for defragmentation. If you've ever tried defragging a full FAT32 filesystem, you know what I'm talking about.
So what *used* to be slapping a chunk of data down onto a disk now becomes a number of moves of data to defragment files, plus your initial write. These defragmentation moves need to be atomic, so you need to be writing some other metadata on the disk. Not only that, we're doing *far* more seeking. Seeking is mind-blowingly expensive compared to writing that chunk of data from before, and the fact that we have to flush the buffers frequently to keep things atomic means that we can't combine as many writes, which means worse seeking.
Without a real world implementation with numbers, it's hard to show you how bad this would be, but every filesystem I've ever used would be far, far, far faster than this.
I should clarify: I see this with users on an Ethernet a few feet away. It's not a firewall issue. :-)