Slashdot Mirror


User: afkmn

afkmn's activity in the archive.

Stories
0
Comments
6
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 6

  1. It's not a bug. on Intel FDIV bug vs ILUVYOU · · Score: 5


    Arguable whether it's a feature, but whatever.

    If I wrote a unix shell script that grepped through a user's home directory for email addresses and then used sendmail to propagate itself to those people, it would be very very similar to the love bug. The -only- significant difference is that Outlook makes it trivially easy to open and run attachments. It's a trojan horse: only works if the user actually launches it.

    Feel free to lambast the intelligence level of your typical Outlook user, but pick your battles.

  2. Misunderstanding? on Attacking Open Source · · Score: 1

    While Mr Taschek may be somewhat ignorant about the nuances of the Community's terminology, I don't think this was as horrible as it sounds. His distinction between Linux (with its bright future) and Open Source (which is doomed) seemed strange, until it became clear that he thought Open Source meant "release source code to get a bunch of free labor", which is, for the most part, what happened with Mozilla.

    Linux, Apache, XFree86, FreeBSD, Gnome, KDE and the long list of excellent projects posters have enumerated in this forum all have one thing in common: their roots are entirely free. They may have commercial ventures associated with them now, but they came FROM the Community, while Mozilla was handed TO the Community. How many major Open Source packages can you think of that started life as proprietary software and then "converted" successfully?

    I've always thought RMS's zealotry with respect to the open source movement was a little loony. I still think he's a loony for other reasons, but on this one, I think I understand where he's coming from. The idea that corporations can sprinkle Magic Open Source Dust on their projects and get a swarm of crack programmers distracts attention from what -really- drives free software: sense of ownership by the community that creates it.

  3. Re:experience with XFS and JFS on XFS to be released under the GPL · · Score: 1
    It can be quite slow in practice; for example, untarring a large amount of scientific data, JFS took three times as much time as ext2, even though it was running on a faster SCSI disk. I haven't done XFS measurements, but XFS also feels sluggish in practice to me.
    It will definitely be slower. It's effectively amortizing the fsck over the write time of the filesystem. Not as slow as lfs, but slow. Note though that ext2fs is an extremely fast filesystem partly due to its fast-and-loose default behavior wrt writes. ufs, by default, writes every byte through to disk. ext2fs just writes to cache.
    It only protects file system structure, not file content.
    Which is why it's faster than lfs...
    It only protects against a small set of failures. For example, hardware failures and file-system related bugs still cause data loss.
    But that set (abnormal terminations, improper shutdown...) constitutes the vast majority of errors in practice.
    JFS comes with a LVM (volume manager) and XFS integrates XLV. In my experience, those kinds of systems complicate disk management, increase the risk of file system management mistakes, and make it more difficult to predict performance.
    complicate perhaps, but it's pretty convenient. Most of my experience is with advfs under Digital Unix, and it was a godsend. Want to see what usage will be like before you divide a new disk into partitions? Make filesets and put hard limits later. Need more space on a low-priority partition? Stick another disk in. Want to reduce restore-from-backup headaches? Make a nightly snapshot. It's not perfect, and there are tradeoffs, but it's nice to have around.
    Journalling does not guarantee fast recovery. There may still be extensive recovery going on at boot time.
    There are no guarantees in life. But our experience has been that real repair has to happen maybe once every 20 bad reboots, if that. YMMV.
    The only time I have actually lost a partition over the last decade was on a journalling file system due to, what appears to have been a software bug in the fs code. Journalling file systems are tricky pieces of software to write. Of course, with XFS on Linux, we can finally compare these issues side-by-side on identical hardware and kernels. It will be interesting how XFS holds up.
    This may be a valid concern. I don't know anything about the buglessness of XFS specifically.
    XFS has some nice features, and I think it will be a great addition to Linux as an optional file system. Its availability will make Linux much more attractive to some corporate buyers.
    There's the rub. And it's made me excited enough to try linux again after a FreeBSD vacation.
  4. Re:Not Worthless on Serious CGI Bug in MacOS X Servers · · Score: 1

    You are absolutely correct that this should not happen. But I suspect that what was meant by that statement was that it was not an inherent, unfixable design problem with OS X, as it would be with the original MacOS, but rather a bug. Even unix kernels have bugs sometimes. May I suggest that we all withhold judgment until we see how long it takes for the patch to arrive. I'd say 48 hours is a fair standard by which to judge a proprietary product.

  5. She-geeks, yes they exist... on Red Hat 'Geek World' Contest · · Score: 1
    Hmm, maybe we could get mattel to lauch "Hacker Barbie" and "Coder Ken"

    Hey! I resemble that remark!

    Seriously, they're out there. Some of them even look good in a bikini. :)

  6. Not Even a Contender on New Compaq Servers (with Closed Source Libs) · · Score: 1

    You are apparently unfamiliar with Digital's engineering. If you don't want proprietary software, fine. That wasn't the argument. But if you have an alpha, Digital's CC runs faster and produces significantly faster code. And digital software is among the most bug-free I've ever encountered. No, nobody's perfect, but they're damned close. Open-source compilers are great if one of two conditions are satisfied: 1) you are a compiler engineer with experience on the platform, or 2) there are lots of people like that out there with an interest in the program. For gcc/alpha, the pool is very small. It hasn't been tuned to the same degree that the intel versions have.

    And part of the reason for that is that the compiler exploits characteristics of the processor that Digital (and now Compaq) might legitimately want to keep secret.