throx writes: The Smart Tag technology was a great idea. People want to be able to enrich their web surfing
How on earth do you know this with such certainty? Are these the same "people" that think that Word (the only word processor!) should automatically capitalize the first letter of whatever it thinks is a sentence? Are these the same "people" that buy so much Budweiser?
You make the fallacious "eat shit, 30 billion flys can't be wrong" argument.
Thanks for staying on topic, Jim. The article we're discussing is titled Senator Says Spammers Have First-Amendment Rights, so it's fair to assume that the spams in question are mere advertisements. But I will deal with your question, even though it isn't a fair question.
Do you REALLY think that restricting bulk email has NO RISK of harming free speech?
Yes, I think that restricting bulk email has exactly no risk of harming free speech. Did restricting advertising (truth in advertising, zoning laws affecting signage and billboards, eliminating cigarette ads from tee vee) harm free speech? Do public nuisance laws, which restrict free speech, harm it? Do anti-fax-spam laws harm free speech? All of these practices restrict free speech without harming it.
You're forgetting that a U.S. Right to free speech DOES NOT IMPLY A RIGHT TO HAVE YOUR FREE SPEECH HEARD.
Treating email spams as what they are (simple theft of disk space, CPU cycles and network connection time) will not harm free speech. Treating advertising spams as free speech will lead to the ruin of SMTP email. Do you REALLY think that treating spams as First Amendment protected speech won't harm our current email system?
Luckily, even illustrious personages like U.S. Senators can make wrong statements. Since email spam is advertising, it is not protected speech,and therefore not covered by the U.S. Constitution's First Amendment.
In fact, the U.S. has recognized over the years that advertising must be controlled - thus we U.S. citizens are protected by "Truth in Advertising" laws.
The real question is who bought off this particular U.S. senator? The Direct Marketing Association (DMA) has its hooks into a lot of state representatives. For instance, here in Colorado, someone proposed a bill to make scumsucking telemarketers use a state "opt-out" list. Colorado citizens could register phone numbers in the opt-out list, and scumsucking telemarketers would be required to *not* call those phone numbers, under penalty of law.
The president of the Colorado State Senate is an ex-DMA-lobbyist, so he used parliamentary procedure to table the bill - it essentially wouldn't even be voted on. A mass outpouring of outrage against evil telemarketers got it back on the table, and it passed.
There can be no compromise on email spam - email spam is theft, and must be eliminated. Email spammers are theives and must be punished withing the limits of the law.
I'm only replying to this one to correct a blatant falsehood, to get the correction into the slashdot record.
Anonymous Coward wrote: Executive Software write part of the Windows NT/2000/XP OS, so naturally they use the NT APIs for certain things below the Win32 level, but for applications developers, there's no advantage to using the native NT API.
It's just stupid to say that. Emulation layers like Win32 always add time to any system call. The Unix world has lots of experience with Mach, an OS similar in some aspects to NT. Emulations of Unix, Linux, VMS or Sprite on top of Mach always cost an unacceptable amount of time. From Sprite on Mach: "Unfortunately, the Sprite server runs the Andrew benchmark at only 38% of the speed of native Sprite."
The reasons an application programmer might want to use the "native" API amount to two very important things:
Speed. See the two references above.
Function. Some things aren't exported from the "native" API to Win32. The simplest example is that the "native" API can do the equivalent of a Unix fork() system call. Win32 cannot. There are other examples of functionality in NT "native", but not in Win32.
There's a huge advantage to using the "native" API, even for a mere application programmer. That's what I loathe the most about you MS-shills: you think you know better than I do what I want to do. It's the very height of arrogance to say that any programmer shouldn't use a particular API that offers more functionality, faster.
Seriously, the managers who invented the "C/C++" phrase need a horse whippin'
Point me to a standard that talks about "C/C++", anything other than some lame "job requirements" document written by Dilber's boss. You can't. "C/C++" doesn't exist. The two languages are diverging, more obviously with the C9x standard.
Windows NT, Windows 2000 and presumably Windows XP had a "native" API that Microsoft never bothered to document publicly. Microsoft has used this on various occasions to aid favored 3rd party vendors (Exececutive Software received access to the native API for "Diskeeper") and to hobble despised 3rd party vendors (Netscape's web server was much slower than IIS, because IIS used the native API, and Netscape used Win32).
Once Microsoft lets people view NT/2000/XP operating system code, the "native" API will be out of the bag. Microsoft won't have semi-secret "native" APIs to barter with.
How much of a force *against* the "shared source" approach was the existance of the "native" API?
The business press (local, national and international) has traditionally been very nice to companies that are currently on top, but the kind of 100% criticism-free reporting that Microsoft gets is just astounding.
No business reporter ever got fired for kissing Microsoft's butt, I guess. This article from Brill's Content describes what happens to reporters who don't toe the M$ line.
OTOH, hitting an asteroid something NASA has to demonstrate they can do. They missed on their first attempt at an asteroid rendezvous and spent a year chasing Eros.
Second, JHUAPL didn't "miss" Eros - see the report....the main engine's normal start-up transient exceeded a lateral acceleration safety threshold that was set too low. It was an onboard software problem. Also, please note that NEAR carried out much more than its planned mission even after the hose-up. You really can't accuse anyone of having trouble "hitting an asteroid".
Re:Where is the bottleneck, really?
on
Benchmark Madness
·
· Score: 1
Barzok writes: Aside from "cache the whole disk in RAM," isn't there a limit to how fast a FS can get, because of the drive?
It's surprising that a Microsoft Shill would actually admit that NTFS is slower than we'd all like.
How is MSFT policy going to change?
on
Shared Source?
·
· Score: 1
Microsoft has been allowing some small access to source code for years. A little less than halfway down this page, there's a summary of a discussion called "Do you need source?" The discussion took place in 1997, and indicates that quite a few academic institutions had access to NT source code back then.
So how does "shared source" change Microsoft's policy about source code? That has never been clear from Mundie's verbiage.
The discussion summary includes this little gem:
The conclusion was that Vogels's group used source code only as documentation (there is no other documentation for NT), examples, and to understand the behavior of NT. It turned out to be useful for debugging, and it led to the discovery of interesting APIs that are not documented or available in Win32.
Slashdot readers (should) be/are fairly intelligent and can probably come to their own conclusions without being sent obviously biased articles.
Oh, please. The shared-source.com web page makes adequate references to sources it cites, unlike non-biased news sites like zdnet or c|net, which rarely if ever give you an outside link to a citation. Readers of shared-source.com are more than free to leave the page and check on the veracity of just about anything stated on that web page.
So, you've gotten just about everything wrong:
You imply that non-biased sources for information on shared source exist, and state openly that shared-source.com is obviously biased. Yet you give no links to or hints as to the existance of these non-biased sources.
Your use of the term yellow journalism is wrong. My dictionary defines yellow journalism as: the use of cheaply sensational or unscrupulous methods in newspapers, etc. to attract or influence the readers. I don't consider shared-source.com to be "cheaply sensational" or "unscrupulous". Apparently you do, but you fail to point out the cheaply sensational and/or unscrupulous features of it.
The shared-source.com page, while obviously biased, has features (like links away from itself) that allow fairly intelligent readers to come to their own conclusions. If you'd cited some non-biased sources that contradict shared-source.com's conclusions, I might have given you points for this one, but you didn't.
Raskin has some curmudgeon in him. Just read this page on what Raskin thinks we should do with the word "intuitive".
Unlike Tog, who seems to think that anything the Mac interface does is The Right Way To Do It, Raskin appears to receive some influence from actually experimentation.
On the other hand, going hard-over against modal interfaces seems a little odd. As far as I know, only one study has ever been done on this sort of thing: "A Comparative Study of Moded and Modeless Text Editing by Experienced Editor Users", by Poller, M.F., Garter, S.K., appearing in Proceedings of CHI '83, pp 166-170.
One interesting conclusion from that study:
Moded errors do not seem to be a problem for experienced vi users. The vi group made few moded errors, and those few were rapidly corrected. Futhermore, modeless editing may not totally avoid moded type errors, since the emacs group made errors that were similar in nature to the vi moded errors.
Despite developing on and for Solaris, I've had to use "Word" to do documentation at several different employers.
Using "Word" makes versioning almost useless - it may be possible to do a "diff" between two versions of a "Word" document, but almost nobody knows how to do so. About the best you can do is put in those goofy "change bars", which makes me feel like I'm in the military, and are fairly easy to overlook. And it only gets worse if Excel "workbooks" are what you're controlling. Most managers use Excel as a way to keep text in columns, because "Word" is so crappy at doing tables.
The real problem you're facing is not finding an appropriate version control system, but whether you should bother with this sort of thing at all. For the most part, "non-technical" people don't seem to care about keeping revisions straight, so I think you'd be fighting an uphill social battle to get them to use any versioning at all.
I used PVCS at my last job. My group developed and deployed on Solaris 2.6, even though almost everybody had NT boxes on their desks. We chose to use the Unix version of PVCS, which nominally ran on Solaris, but actually didn't. It actually only ran on HP-UX. We ended up with a really half-baked system where HP-UX machines running PVCS and our development machines NFS mounted a partition served by an Auspex NFS server. We'd log in to the HP-UX machine, set DISPLAY to desktop machine, and check-out into the NFS-mounted partition. Then, we'd log in to the Solaris development machines to develop, compile and unit test.
PVCS for Unix is an absolute and utter mess. DO NOT let yourself be contaminated by the bug-ridden and awful terror that is PVCS. The GUI (Java app) is a heinous, bug-ridden piece of excrement with incredibly poor user interface. The GUI is slow, and has so many human factors problems that developers occasionally checked-in files in the wrong directory. The GUI doesn't do a good job of mapping "archives" to directories, and it doesn't map from directory to "archive" at all. This leads it to offer you a selection of "Makefile" archives, and you get to choose which one. You must understand the internal structure of the PVCS archive directory tree to choose the right archive. PVCS seems to think that all files have an "extension", whatever the hell that is, and if you have files (like "Makefile") that don't have an extension, it won't expand RCS keywords ($Id$, etc). The back-end is equally buggy. We had a more-or-less half time PVCS administrator, whose job included deleting lockfiles that PVCS would occasionally leave around.
The company I used to work for chose PVCS for two public reasons: (1) it's nominally multi-platform (we found out that it isn't, Merant only claims it is) and (2) it had really, really elaborate management interfaces into the bug lifecycle. This makes managers happy, but leads to lots of ugly "WTF do we do with this bug report?" meetings at the end of a development cycle, the day before a release.
I run NetBSD on my old SPARCs (IPC and SS-10). That's a sun4c and sun4m architecture. The NetBSD folks managed to do something that Sun never did: get a single kernel to run on both sun4c and sun4m architectures.
Anyway, NetBSD doesn't come with the massive amounts of pre-compiled applications that Linux distros do, but you can typically get a "pkg" for the applications you do want.
To my fingers, NetBSD feels a lot like SunOS 4.1.3, which I happened to like a lot. If anything, NetBSD 1.5 is speedier on older hardware than Sun's SunOS was.
Re:Reasons *not* to use NTFS
on
NTFS vs. FAT32
·
· Score: 1
... this is most likely for a home machine... how many of NetBSD's multiple file systems are journalling and support ACL's?.
Do I detect an internally-inconsistent argument from an MS apologist?
Unix user IDs and permissions are far too restrictive for the home user, but the home user needs ACLs and a journalling filesystem. The goal is always just out of reach isn't it fudster?
Ok, given that NetBSD uses FFS as its "native" filesystem, and FFS dates back to, what the early 80s, I'd say that it's had years of being proven through use, far more than NTFS has had. NetBSD also supports LFS, the log-structured filesystem. LFS doesn't need journalling: it is a journal. ACLs, I confess, seem to be beyond NetBSD. Other than that, I think your conclusion is dead wrong: if there's anything that open source operating systems are good for, it's a variety of filesystems.
Reasons *not* to use NTFS
on
NTFS vs. FAT32
·
· Score: 1
NTFS isn't the cure-all that MSFT makes it out to be. It has some problems.
It allocates disk sectors in extents - therefore, it absolutely requires defragmentation. See Executive Software's Diskeeper benchmarks, and their white paper. You don't have to believe Executive Software, and there may be good reasons for disbelieving them. Think about it: every other filesystem that has had extent-based allocation ended up with defragementers: DEC's ODS-2 (VMS), SGI's EFS (Irix) are two examples of radically different filesystems by radically different vendors, yet each required defragmentation. Fortunately, SGI provided such a good one, that 3rd party vendors didn't even bother.
Each file has multiple "streams". These could very obviously promote security problems. Alternatively, see this for another example. Microsoft itself has had a bunch of problems with NTFS streams, including bizarre interactions with IIS.
It's broken by design. Any fool can extend the MFT and use up all of a partition's disk space.
If you insist on using a closed system, you don't get that many choices. For a lot of filesytem choices, I'd reccommend NetBSD.
Maybe peer-to-peer sucks, and maybe it isn't "the future of the Internet", but it ought to be.
The Internet, as it exists today, is peer-to-peer because of the nature of the Internet Protocol. Distinctions between "clients" and "servers" are made only and solely at protocol levels above IP (TCP or UDP or FTP or Telnet or HTTP), and even then the distinction is sometimes pretty hazy. And this is a Good Thing. This underlying peer-to-peer nature is the only thing that's allowed the explosive creativity (Slashdot, HotOrNot, Ebay, Yahoo, &etc) we've witnessed. If The Internet was not peer-to-peer, any entity acting as a "server" would be strictly controlled by some corporate entity (think CompuServe, Delphi, and GEnie), and you'd be buying your "client" from the corporate entity. Only corporate-approved material would get on the server (Think Terms-of-service), and only corporate-approved applications would run on the server (think AOL). The only creativity allowed would be at the fringes, like AIMster, or the old AOL practice of exchanging naughty tease pictures via AOL email.
In this age of convicted suffocating monopolies and massive media conglomeration mergers, Peer-to-peer may constitute the only way that a single person (Matt Drudge) can fight against Time-Warner/AOL/CNN/AT&T. We'd better hope and pray until our palms bleed that peer-to-peer doesn't suck.
Cross platform worms have existed since at least 1988: the RTM Nov '88 Internet worm infected both Sun3 (M68020) and DEC VAX hardware. The Cornell report on that worm implies that the source code had slots for executables for other types of hardware, too.
So, no, Word macro viruses weren't the first cross-platform anything. Just another case of a supposed MSFT "innovation" turning out to be a cheap imitation instead.
If they can put a "V" chip in a Tee Vee, they sure ought to put a "C" chip in there, too. "C" in this case means "commercial". If there's a pernicious element to current Tee Vee programming, it's those damn commercials, teaching your kids to be sluts like Britney Spears, promoting unrealistic values, increasing soulless, godless consumerism.
Re:Should be taken seriously?
on
New Linux Worm
·
· Score: 1
As a matter of fact, it's well documented that MSFT does "stooge" much smaller on-line forums.
From Brill's Content, Sept 1998:
In 1992, the Microsoft evangelists began paying attention to on-line bulletin boards. "All of a sudden, press people started hanging out on CompuServe [home of the influential Canopus forum], and started using the forums as sources of information," says Segal, who monitored about 25 forums. Identifying themselves as Microsoft employees, Segal says, he and his colleagues would post retorts to anything they saw that portrayed Windows or Microsoft in a bad light.
IBM began to understand what was going on, and it appointed a lone OS/2 evangelist, David Whittle. He gamely joined the fray, posting items on the Canopus forum, which Microsoft now regarded as a hotbed of anti-Windows, pro-OS/2 sentiment, says Segal. The evangelists jumped on the outgunned Whittle. "It's outrageous how IBM sent him in with a pea shooter," recalls Segal. "We were going to cream him, pick him apart, slaughter him."
The CompuServe OS/2 forum probably had a much smaller readership (and influence) than Slashdot has today.
On April 10, 1999 the Los Angeles Times reported that Microsoft "has secretly been planning a massive media campaign designed to influence state investigators by creating the appearance of a groundswell of public support for the company". Plans for the campaign included planting articles, and commissioning letters to the editor and opinion pieces written by Microsoft media handlers, but presented as "spontaneous testimonials."
So, yes, I seriously do think that MSFT "stooges" Slashdot. MSFT has such a track record that I believe any pro-MSFT opinion expressed in a public forum has to be viewed with a fair amount of suspicion.
Should be taken seriously?
on
New Linux Worm
·
· Score: 1
The "SANS" report says something interesting: Lion is a new worm, that is very similar to the Ramen worm. However, this worm is much more dangerous and should be taken seriously..
Does this mean that the Ramen worm wasn't worth taking seriously? If so, why did the press make such an incredible stink about it? How many infections did Ramen have, and how many does Lion have?
As far as the Microsoft shills who say that now they (the paid MSFT shills) can poke fun at Linux for having a virus problem: You can do that the minute that some Indonesian Teen writes a virus-making-kit for Linux, and a Slovakian Teen paralyzes a few country's email systems with a kit-written-worm named after a chick sports celebrity.
Until then, all you MSFT shills have is a monoculture with universally-inherited weaknesses (Outlook, Windows scripting host), led by a corporation whose only idea of security is to keep the people from copying the data they legally own.
Fake fan sites are eerily reminiscent of Bruce Schneier's Semantic Attacks, except that the movie industry is doing it so damn clumsily, and in public.
I agree that fake fan sites are dopey, and won't work. I mean, what attracted Joe Sixpack to The Internet in 1996 and 1997? Was it slick, pre-digested Corporate Ad Collateral? No just "No", but "Hell, NO". What attracts people to The Internet is what other individuals have put out there, whether it be Harry Potter fan sites, Hollywood Bitchslap movie reviews, or AmIHotOrNot. The current upper leadership of mass media outlets just doesn't get it.
Slashdot Mirror
throx writes: The Smart Tag technology was a great idea. People want to be able to enrich their web surfing
How on earth do you know this with such certainty? Are these the same "people" that think that Word (the only word processor!) should automatically capitalize the first letter of whatever it thinks is a sentence? Are these the same "people" that buy so much Budweiser?
You make the fallacious "eat shit, 30 billion flys can't be wrong" argument.
Thanks for staying on topic, Jim. The article we're discussing is titled Senator Says Spammers Have First-Amendment Rights, so it's fair to assume that the spams in question are mere advertisements. But I will deal with your question, even though it isn't a fair question.
Do you REALLY think that restricting bulk email has NO RISK of harming free speech?
Yes, I think that restricting bulk email has exactly no risk of harming free speech. Did restricting advertising (truth in advertising, zoning laws affecting signage and billboards, eliminating cigarette ads from tee vee) harm free speech? Do public nuisance laws, which restrict free speech, harm it? Do anti-fax-spam laws harm free speech? All of these practices restrict free speech without harming it.
You're forgetting that a U.S. Right to free speech DOES NOT IMPLY A RIGHT TO HAVE YOUR FREE SPEECH HEARD.
Treating email spams as what they are (simple theft of disk space, CPU cycles and network connection time) will not harm free speech. Treating advertising spams as free speech will lead to the ruin of SMTP email. Do you REALLY think that treating spams as First Amendment protected speech won't harm our current email system?
Luckily, even illustrious personages like U.S. Senators can make wrong statements. Since email spam is advertising, it is not protected speech,and therefore not covered by the U.S. Constitution's First Amendment.
In fact, the U.S. has recognized over the years that advertising must be controlled - thus we U.S. citizens are protected by "Truth in Advertising" laws.
The real question is who bought off this particular U.S. senator? The Direct Marketing Association (DMA) has its hooks into a lot of state representatives. For instance, here in Colorado, someone proposed a bill to make scumsucking telemarketers use a state "opt-out" list. Colorado citizens could register phone numbers in the opt-out list, and scumsucking telemarketers would be required to *not* call those phone numbers, under penalty of law.
The president of the Colorado State Senate is an ex-DMA-lobbyist, so he used parliamentary procedure to table the bill - it essentially wouldn't even be voted on. A mass outpouring of outrage against evil telemarketers got it back on the table, and it passed.
There can be no compromise on email spam - email spam is theft, and must be eliminated. Email spammers are theives and must be punished withing the limits of the law.
I'm only replying to this one to correct a blatant falsehood, to get the correction into the slashdot record.
Anonymous Coward wrote: Executive Software write part of the Windows NT/2000/XP OS, so naturally they use the NT APIs for certain things below the Win32 level, but for applications developers, there's no advantage to using the native NT API.
It's just stupid to say that. Emulation layers like Win32 always add time to any system call. The Unix world has lots of experience with Mach, an OS similar in some aspects to NT. Emulations of Unix, Linux, VMS or Sprite on top of Mach always cost an unacceptable amount of time. From Sprite on Mach: "Unfortunately, the Sprite server runs the Andrew benchmark at only 38% of the speed of native Sprite."
From Linux on the OSF Mach3 microkernel: "Often, as much as a 40% performance cost has been reported."
The reasons an application programmer might want to use the "native" API amount to two very important things:
There's a huge advantage to using the "native" API, even for a mere application programmer. That's what I loathe the most about you MS-shills: you think you know better than I do what I want to do. It's the very height of arrogance to say that any programmer shouldn't use a particular API that offers more functionality, faster.
Seriously, the managers who invented the "C/C++" phrase need a horse whippin'
Point me to a standard that talks about "C/C++", anything other than some lame "job requirements" document written by Dilber's boss. You can't. "C/C++" doesn't exist. The two languages are diverging, more obviously with the C9x standard.
Windows NT, Windows 2000 and presumably Windows XP had a "native" API that Microsoft never bothered to document publicly. Microsoft has used this on various occasions to aid favored 3rd party vendors (Exececutive Software received access to the native API for "Diskeeper") and to hobble despised 3rd party vendors (Netscape's web server was much slower than IIS, because IIS used the native API, and Netscape used Win32).
Once Microsoft lets people view NT/2000/XP operating system code, the "native" API will be out of the bag. Microsoft won't have semi-secret "native" APIs to barter with.
How much of a force *against* the "shared source" approach was the existance of the "native" API?
they're not saying that WinNT isn't that much less secure or stable
Wurzler doesn't have to say that, everybody already knows it: WIN2K is even easier to deface than NT.
The business press (local, national and international) has traditionally been very nice to companies that are currently on top, but the kind of 100% criticism-free reporting that Microsoft gets is just astounding.
No business reporter ever got fired for kissing Microsoft's butt, I guess. This article from Brill's Content describes what happens to reporters who don't toe the M$ line.
OTOH, hitting an asteroid something NASA has to demonstrate they can do. They missed on their first attempt at an asteroid rendezvous and spent a year chasing Eros.
First, Johns Hopkins University Applied Physics Lab did all the mission design.
Second, JHUAPL didn't "miss" Eros - see the report. ...the main engine's normal start-up transient exceeded a lateral acceleration safety threshold that was set too low. It was an onboard software problem. Also, please note that NEAR carried out much more than its planned mission even after the hose-up. You really can't accuse anyone of having trouble "hitting an asteroid".
Barzok writes: Aside from "cache the whole disk in RAM," isn't there a limit to how fast a FS can get, because of the drive?
Log structured filesystems are supposed to achieve nearly the disk write speed. At least naively, one would also think they'd get better speed than "journalled" filesystems, because the filesystem itself constitutes a journal.
Some folks seem to think that clustered writes give you nearly the same performance, though.
Pod writes: The reason NTFS (for example) doesn't perform as fast as you'd expect is because it does journaling, which slows it down very much.
Are you that sure that journaling is the only reason NTFS performs poorly? What about NTFS's extreme tendency towards fragmentation? What about MFT fragmentation?
It's surprising that a Microsoft Shill would actually admit that NTFS is slower than we'd all like.
Microsoft has been allowing some small access to source code for years. A little less than halfway down this page, there's a summary of a discussion called "Do you need source?" The discussion took place in 1997, and indicates that quite a few academic institutions had access to NT source code back then.
So how does "shared source" change Microsoft's policy about source code? That has never been clear from Mundie's verbiage.
The discussion summary includes this little gem:
Will "shared source" allow people to suss out the Microsoft secret APIs? How is Microsoft going to deal with that? Won't previous receipiants of secret APIs get a little steamed when others get hold of them?Slashdot readers (should) be/are fairly intelligent and can probably come to their own conclusions without being sent obviously biased articles.
Oh, please. The shared-source.com web page makes adequate references to sources it cites, unlike non-biased news sites like zdnet or c|net, which rarely if ever give you an outside link to a citation. Readers of shared-source.com are more than free to leave the page and check on the veracity of just about anything stated on that web page.
So, you've gotten just about everything wrong:
Raskin has some curmudgeon in him. Just read this page on what Raskin thinks we should do with the word "intuitive".
Unlike Tog, who seems to think that anything the Mac interface does is The Right Way To Do It, Raskin appears to receive some influence from actually experimentation.
On the other hand, going hard-over against modal interfaces seems a little odd. As far as I know, only one study has ever been done on this sort of thing: "A Comparative Study of Moded and Modeless Text Editing by Experienced Editor Users", by Poller, M.F., Garter, S.K., appearing in Proceedings of CHI '83, pp 166-170.
One interesting conclusion from that study:
Despite developing on and for Solaris, I've had to use "Word" to do documentation at several different employers.
Using "Word" makes versioning almost useless - it may be possible to do a "diff" between two versions of a "Word" document, but almost nobody knows how to do so. About the best you can do is put in those goofy "change bars", which makes me feel like I'm in the military, and are fairly easy to overlook. And it only gets worse if Excel "workbooks" are what you're controlling. Most managers use Excel as a way to keep text in columns, because "Word" is so crappy at doing tables.
The real problem you're facing is not finding an appropriate version control system, but whether you should bother with this sort of thing at all. For the most part, "non-technical" people don't seem to care about keeping revisions straight, so I think you'd be fighting an uphill social battle to get them to use any versioning at all.
I used PVCS at my last job. My group developed and deployed on Solaris 2.6, even though almost everybody had NT boxes on their desks. We chose to use the Unix version of PVCS, which nominally ran on Solaris, but actually didn't. It actually only ran on HP-UX. We ended up with a really half-baked system where HP-UX machines running PVCS and our development machines NFS mounted a partition served by an Auspex NFS server. We'd log in to the HP-UX machine, set DISPLAY to desktop machine, and check-out into the NFS-mounted partition. Then, we'd log in to the Solaris development machines to develop, compile and unit test.
PVCS for Unix is an absolute and utter mess. DO NOT let yourself be contaminated by the bug-ridden and awful terror that is PVCS. The GUI (Java app) is a heinous, bug-ridden piece of excrement with incredibly poor user interface. The GUI is slow, and has so many human factors problems that developers occasionally checked-in files in the wrong directory. The GUI doesn't do a good job of mapping "archives" to directories, and it doesn't map from directory to "archive" at all. This leads it to offer you a selection of "Makefile" archives, and you get to choose which one. You must understand the internal structure of the PVCS archive directory tree to choose the right archive. PVCS seems to think that all files have an "extension", whatever the hell that is, and if you have files (like "Makefile") that don't have an extension, it won't expand RCS keywords ($Id$, etc). The back-end is equally buggy. We had a more-or-less half time PVCS administrator, whose job included deleting lockfiles that PVCS would occasionally leave around.
The company I used to work for chose PVCS for two public reasons: (1) it's nominally multi-platform (we found out that it isn't, Merant only claims it is) and (2) it had really, really elaborate management interfaces into the bug lifecycle. This makes managers happy, but leads to lots of ugly "WTF do we do with this bug report?" meetings at the end of a development cycle, the day before a release.
I strongly reccomend you avoid PVCS.
I run NetBSD on my old SPARCs (IPC and SS-10). That's a sun4c and sun4m architecture. The NetBSD folks managed to do something that Sun never did: get a single kernel to run on both sun4c and sun4m architectures.
Anyway, NetBSD doesn't come with the massive amounts of pre-compiled applications that Linux distros do, but you can typically get a "pkg" for the applications you do want.
To my fingers, NetBSD feels a lot like SunOS 4.1.3, which I happened to like a lot. If anything, NetBSD 1.5 is speedier on older hardware than Sun's SunOS was.
... this is most likely for a home machine ... how many of NetBSD's multiple file systems are journalling and support ACL's?.
Do I detect an internally-inconsistent argument from an MS apologist?
Unix user IDs and permissions are far too restrictive for the home user, but the home user needs ACLs and a journalling filesystem. The goal is always just out of reach isn't it fudster?
Ok, given that NetBSD uses FFS as its "native" filesystem, and FFS dates back to, what the early 80s, I'd say that it's had years of being proven through use, far more than NTFS has had. NetBSD also supports LFS, the log-structured filesystem. LFS doesn't need journalling: it is a journal. ACLs, I confess, seem to be beyond NetBSD. Other than that, I think your conclusion is dead wrong: if there's anything that open source operating systems are good for, it's a variety of filesystems.
- It allocates disk sectors in extents - therefore, it absolutely requires defragmentation. See Executive Software's Diskeeper benchmarks, and their white paper. You don't have to believe Executive Software, and there may be good reasons for disbelieving them. Think about it: every other filesystem that has had extent-based allocation ended up with defragementers: DEC's ODS-2 (VMS), SGI's EFS (Irix) are two examples of radically different filesystems by radically different vendors, yet each required defragmentation. Fortunately, SGI provided such a good one, that 3rd party vendors didn't even bother.
- Each file has multiple "streams". These could very obviously promote security problems. Alternatively, see this for another example. Microsoft itself has had a bunch of problems with NTFS streams, including bizarre interactions with IIS.
- It's broken by design. Any fool can extend the MFT and use up all of a partition's disk space.
If you insist on using a closed system, you don't get that many choices. For a lot of filesytem choices, I'd reccommend NetBSD.Maybe peer-to-peer sucks, and maybe it isn't "the future of the Internet", but it ought to be.
The Internet, as it exists today, is peer-to-peer because of the nature of the Internet Protocol. Distinctions between "clients" and "servers" are made only and solely at protocol levels above IP (TCP or UDP or FTP or Telnet or HTTP), and even then the distinction is sometimes pretty hazy. And this is a Good Thing. This underlying peer-to-peer nature is the only thing that's allowed the explosive creativity (Slashdot, HotOrNot, Ebay, Yahoo, &etc) we've witnessed. If The Internet was not peer-to-peer, any entity acting as a "server" would be strictly controlled by some corporate entity (think CompuServe, Delphi, and GEnie), and you'd be buying your "client" from the corporate entity. Only corporate-approved material would get on the server (Think Terms-of-service), and only corporate-approved applications would run on the server (think AOL). The only creativity allowed would be at the fringes, like AIMster, or the old AOL practice of exchanging naughty tease pictures via AOL email.
In this age of convicted suffocating monopolies and massive media conglomeration mergers, Peer-to-peer may constitute the only way that a single person (Matt Drudge) can fight against Time-Warner/AOL/CNN/AT&T. We'd better hope and pray until our palms bleed that peer-to-peer doesn't suck.
Cross platform worms have existed since at least 1988: the RTM Nov '88 Internet worm infected both Sun3 (M68020) and DEC VAX hardware. The Cornell report on that worm implies that the source code had slots for executables for other types of hardware, too.
Shell script viruses should be pretty much cross-platform on all unix-a-like systems, too. A fellow named Keith McMillan wrote a master's thesis on how to write a cross-platform virus in TeX and Emacs.
So, no, Word macro viruses weren't the first cross-platform anything. Just another case of a supposed MSFT "innovation" turning out to be a cheap imitation instead.
If they can put a "V" chip in a Tee Vee, they sure ought to put a "C" chip in there, too. "C" in this case means "commercial". If there's a pernicious element to current Tee Vee programming, it's those damn commercials, teaching your kids to be sluts like Britney Spears, promoting unrealistic values, increasing soulless, godless consumerism.
As a matter of fact, it's well documented that MSFT does "stooge" much smaller on-line forums. From Brill's Content, Sept 1998:
The CompuServe OS/2 forum probably had a much smaller readership (and influence) than Slashdot has today.
MSFT has paid for newspaper ads nominally authored by and independent 3rd party.
On April 10, 1999 the Los Angeles Times reported that Microsoft "has secretly been planning a massive media campaign designed to influence state investigators by creating the appearance of a groundswell of public support for the company". Plans for the campaign included planting articles, and commissioning letters to the editor and opinion pieces written by Microsoft media handlers, but presented as "spontaneous testimonials."
So, yes, I seriously do think that MSFT "stooges" Slashdot. MSFT has such a track record that I believe any pro-MSFT opinion expressed in a public forum has to be viewed with a fair amount of suspicion.
The "SANS" report says something interesting: Lion is a new worm, that is very similar to the Ramen worm. However, this worm is much more dangerous and should be taken seriously..
Does this mean that the Ramen worm wasn't worth taking seriously? If so, why did the press make such an incredible stink about it? How many infections did Ramen have, and how many does Lion have?
As far as the Microsoft shills who say that now they (the paid MSFT shills) can poke fun at Linux for having a virus problem: You can do that the minute that some Indonesian Teen writes a virus-making-kit for Linux, and a Slovakian Teen paralyzes a few country's email systems with a kit-written-worm named after a chick sports celebrity.
Until then, all you MSFT shills have is a monoculture with universally-inherited weaknesses (Outlook, Windows scripting host), led by a corporation whose only idea of security is to keep the people from copying the data they legally own.
The Warner Bros. studio has tried to get Harry Potter fan sites taken down. Warner Bros. is currently backing off on this.
Fake fan sites are eerily reminiscent of Bruce Schneier's Semantic Attacks, except that the movie industry is doing it so damn clumsily, and in public.
I agree that fake fan sites are dopey, and won't work. I mean, what attracted Joe Sixpack to The Internet in 1996 and 1997? Was it slick, pre-digested Corporate Ad Collateral? No just "No", but "Hell, NO". What attracts people to The Internet is what other individuals have put out there, whether it be Harry Potter fan sites, Hollywood Bitchslap movie reviews, or AmIHotOrNot. The current upper leadership of mass media outlets just doesn't get it.